* does graphite affect the c++ munging? Does -On? @ 2012-11-04 23:10 James Cloos 2012-11-05 0:32 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: James Cloos @ 2012-11-04 23:10 UTC (permalink / raw) To: gcc-help I'm seeing an unexpected undefined reference error from ld(1) for a package which uses icu. The error is dependent on CXXFLAGS, notably the three graphite flags. Although, now that I try to duplicate that, I cannot and get the same undefined refs every time. :-/ The first undefined ref is to: icu::LEFontInstance::mapCharsToGlyphs(unsigned short const*, int, int, signed char, icu::LECharMapper const*, signed char, icu::LEGlyphStorage&) const The definition in icu's src is: void LEFontInstance::mapCharsToGlyphs(const LEUnicode chars[], le_int32 offset, le_int32 count, le_bool reverse, const LECharMapper *mapper, le_bool filterZeroWidth, LEGlyphStorage &glyphStorage) const and the library has: _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKDsiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE which I presume splits out as: E PK Ds i i a PK NS_12LECharMapper E a R NS_14LEGlyphStorage E which seems to match, presuming PKDs is a pointer to ushort, and a is a signed char. Strace(1) shows that ld(1) reads the correct files, so it isn't due to old stuff hinding on the fs. This is with gcc 4.7.2. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: does graphite affect the c++ munging? Does -On? 2012-11-04 23:10 does graphite affect the c++ munging? Does -On? James Cloos @ 2012-11-05 0:32 ` Jonathan Wakely 2012-11-05 1:07 ` James Cloos 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2012-11-05 0:32 UTC (permalink / raw) To: James Cloos; +Cc: gcc-help On 4 November 2012 23:09, James Cloos wrote: > > I'm seeing an unexpected undefined reference error from ld(1) for a > package which uses icu. > > The error is dependent on CXXFLAGS, notably the three graphite flags. > > Although, now that I try to duplicate that, I cannot and get the same > undefined refs every time. :-/ > > The first undefined ref is to: > > icu::LEFontInstance::mapCharsToGlyphs(unsigned short const*, > int, > int, > signed char, > icu::LECharMapper const*, > signed char, > icu::LEGlyphStorage&) const > > The definition in icu's src is: > > void LEFontInstance::mapCharsToGlyphs(const LEUnicode chars[], > le_int32 offset, > le_int32 count, > le_bool reverse, > const LECharMapper *mapper, > le_bool filterZeroWidth, > LEGlyphStorage &glyphStorage) const > > and the library has: > > _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKDsiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE > > which I presume splits out as: > > E PK Ds i i a PK NS_12LECharMapper E a R NS_14LEGlyphStorage E > > which seems to match, presuming PKDs is a pointer to ushort, and a is > a signed char. It doesn't match, c++filt shows that symbol is icu::LEFontInstance::mapCharsToGlyphs(char16_t const*, int, int, signed char, icu::LECharMapper const*, signed char, icu::LEGlyphStorage&) const char16_t is not unsigned short. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: does graphite affect the c++ munging? Does -On? 2012-11-05 0:32 ` Jonathan Wakely @ 2012-11-05 1:07 ` James Cloos 2012-11-05 3:11 ` Philipp Thomas 0 siblings, 1 reply; 8+ messages in thread From: James Cloos @ 2012-11-05 1:07 UTC (permalink / raw) To: gcc-help; +Cc: Jonathan Wakely >>>>> "JW" == Jonathan Wakely <jwakely.gcc@gmail.com> writes: JW> It doesn't match, c++filt shows that symbol is Ah, thanks. I'll check out c++filt. JW> icu::LEFontInstance::mapCharsToGlyphs(char16_t const*, int, int, JW> signed char, icu::LECharMapper const*, signed char, JW> icu::LEGlyphStorage&) const JW> char16_t is not unsigned short. OK. That said: :; g++ -march=amdfam10 -dM -E - </dev/null | grep CHAR16 #define __CHAR16_TYPE__ short unsigned int #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2 Where should I look for why, given __CHAR16_TYPE__ is short unsigned int, the compile of icu munges differently than the consumer of icu munges? -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: does graphite affect the c++ munging? Does -On? 2012-11-05 1:07 ` James Cloos @ 2012-11-05 3:11 ` Philipp Thomas 2012-11-05 18:23 ` James Cloos 0 siblings, 1 reply; 8+ messages in thread From: Philipp Thomas @ 2012-11-05 3:11 UTC (permalink / raw) To: gcc-help On Sun, 04 Nov 2012 20:01:11 -0500, James Cloos <cloos@jhcloos.com> wrote: >Where should I look for why, given __CHAR16_TYPE__ is short unsigned int, >the compile of icu munges differently than the consumer of icu munges? For me it looks like the header doesn't match the library. If using a Linux distribution, have you checked that library and devel package match? Philipp ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: does graphite affect the c++ munging? Does -On? 2012-11-05 3:11 ` Philipp Thomas @ 2012-11-05 18:23 ` James Cloos 2012-11-05 18:34 ` Jonathan Wakely 2012-11-05 18:41 ` [HarfBuzz] " Jonathan Kew 0 siblings, 2 replies; 8+ messages in thread From: James Cloos @ 2012-11-05 18:23 UTC (permalink / raw) To: gcc-help, harfbuzz; +Cc: Philipp Thomas [Background for the harfbuzz readers: hb fails to compile with icu 50_rc and gcc 4.7.2 with an inconsistancy between what icu provides for LEFontInstance::mapCharsToGlyphs() and that hb wants.] >>>>> "PT" == Philipp Thomas <Philipp.Thomas2@gmx.net> writes: PT> For me it looks like the header doesn't match the library. I looked again in case I missed anything last night. /usr/include/layout/LEFontInstance.h has: virtual void mapCharsToGlyphs(const LEUnicode chars[], le_int32 offset, le_int32 count, le_bool reverse, const LECharMapper *mapper, le_bool filterZeroWidth, LEGlyphStorage &glyphStorage) const; icu(-50_rc)/source/layout/LEFontInstance.cpp has: LEFontInstance::mapCharsToGlyphs(const LEUnicode chars[], le_int32 offset, le_int32 count, le_bool reverse, const LECharMapper *mapper, le_bool filterZeroWidth, LEGlyphStorage &glyphStorage) const /usr/lib/libicule.so provides: _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKDsiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE which c++filt expands to: icu::LEFontInstance::mapCharsToGlyphs(char16_t const*, int, int, signed char, icu::LECharMapper const*, signed char, icu::LEGlyphStorage&) const But hb's libhb_icu_le_la-PortableFontInstance.o wants: _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKtiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE which c++filt expands to: icu::LEFontInstance::mapCharsToGlyphs(unsigned short const*, int, int, signed char, icu::LECharMapper const*, signed char, icu::LEGlyphStorage&) const It seems that icu's LEUnicode typedef is converted differently. And, to make it harder to debug, hb doesn't call mapCharsToGlyphs() at all. nm(1) finds it in the .o file, but objdump -d does not. I tried adding -dM -E to the g++ invocation hb uses for that file and found: #define U_HAVE_CHAR16_T 0 #define __CHAR16_TYPE__ short unsigned int which might have something to do with the different munging. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: does graphite affect the c++ munging? Does -On? 2012-11-05 18:23 ` James Cloos @ 2012-11-05 18:34 ` Jonathan Wakely 2012-11-05 18:46 ` Jonathan Wakely 2012-11-05 18:41 ` [HarfBuzz] " Jonathan Kew 1 sibling, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2012-11-05 18:34 UTC (permalink / raw) To: James Cloos; +Cc: gcc-help, harfbuzz, Philipp Thomas On 5 November 2012 18:15, James Cloos wrote: > [Background for the harfbuzz readers: > > hb fails to compile with icu 50_rc and gcc 4.7.2 with an inconsistancy > between what icu provides for LEFontInstance::mapCharsToGlyphs() and > that hb wants.] > >>>>>> "PT" == Philipp Thomas <Philipp.Thomas2@gmx.net> writes: > > PT> For me it looks like the header doesn't match the library. > > I looked again in case I missed anything last night. > > /usr/include/layout/LEFontInstance.h has: > > virtual void mapCharsToGlyphs(const LEUnicode chars[], > le_int32 offset, > le_int32 count, > le_bool reverse, > const LECharMapper *mapper, > le_bool filterZeroWidth, > LEGlyphStorage &glyphStorage) const; > > icu(-50_rc)/source/layout/LEFontInstance.cpp has: > > LEFontInstance::mapCharsToGlyphs(const LEUnicode chars[], > le_int32 offset, > le_int32 count, > le_bool reverse, > const LECharMapper *mapper, > le_bool filterZeroWidth, > LEGlyphStorage &glyphStorage) const > > /usr/lib/libicule.so provides: > > _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKDsiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE > > which c++filt expands to: > > icu::LEFontInstance::mapCharsToGlyphs(char16_t const*, > int, > int, > signed char, > icu::LECharMapper const*, > signed char, > icu::LEGlyphStorage&) const > > > But hb's libhb_icu_le_la-PortableFontInstance.o wants: > > _ZNK3icu14LEFontInstance16mapCharsToGlyphsEPKtiiaPKNS_12LECharMapperEaRNS_14LEGlyphStorageE > > which c++filt expands to: > > icu::LEFontInstance::mapCharsToGlyphs(unsigned short const*, > int, > int, > signed char, > icu::LECharMapper const*, > signed char, > icu::LEGlyphStorage&) const > > It seems that icu's LEUnicode typedef is converted differently. Typedefs aren't "converted" they're defined. If the typedef if different in two places it's because it's defined differently. Find where it's defined, see what it's defined to, if that definition depends on some condition, find what it is and what it's value is when compiling ICU and when compiling your program. > And, to make it harder to debug, hb doesn't call mapCharsToGlyphs() at all. > > nm(1) finds it in the .o file, but objdump -d does not. > > I tried adding -dM -E to the g++ invocation hb uses for that file and found: > > #define U_HAVE_CHAR16_T 0 > #define __CHAR16_TYPE__ short unsigned int > > which might have something to do with the different munging. You mean mangling, not munging, but the mangling is not the problem, the compiler is mangling the argument types differently because they're different types. When compiling the ICU sources it apparently has a different definition of the LEUnicode typedef than when you include the header. __CHAR16_TYPE__ is also a red herring, in C++ char16_t is a unique type, not just a typedef for some other type. __CHAR16_TYPE__ isn't the same type as char16_t in C++. My guess is there's code that looks like: #if __cplusplus >= 201103L typedef char16_t LEUnicode; #else typedef unsigned short LEUnicode; #endif and the library was built with -std=c++11 and harfbuzz is not. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: does graphite affect the c++ munging? Does -On? 2012-11-05 18:34 ` Jonathan Wakely @ 2012-11-05 18:46 ` Jonathan Wakely 0 siblings, 0 replies; 8+ messages in thread From: Jonathan Wakely @ 2012-11-05 18:46 UTC (permalink / raw) To: James Cloos; +Cc: gcc-help, harfbuzz, Philipp Thomas On 5 November 2012 18:34, Jonathan Wakely wrote: > > My guess is there's code that looks like: > > #if __cplusplus >= 201103L > typedef char16_t LEUnicode; > #else > typedef unsigned short LEUnicode; > #endif > > and the library was built with -std=c++11 and harfbuzz is not. And it looks as though I'm almost spot on, http://source.icu-project.org/repos/icu/icu/trunk/source/common/unicode/umachine.h has: /* Define UChar to be compatible with char16_t or wchar_t if possible. */ #if U_HAVE_CHAR16_T typedef char16_t UChar; #elif U_SIZEOF_WCHAR_T==2 typedef wchar_t UChar; #elif defined(__CHAR16_TYPE__) typedef __CHAR16_TYPE__ UChar; #else typedef uint16_t UChar; #endif and http://source.icu-project.org/repos/icu/icu/trunk/source/common/unicode/platform.h has #ifdef U_HAVE_CHAR16_T /* Use the predefined value. */ #else /* * Notes: * Visual Studio 10 (_MSC_VER>=1600) defines char16_t but * does not support u"abc" string literals. * gcc 4.4 defines the __CHAR16_TYPE__ macro to a usable type but * does not support u"abc" string literals. * C++11 requires support for UTF-16 literals */ # if (defined(__cplusplus) && __cplusplus >= 201103L) # define U_HAVE_CHAR16_T 1 # else # define U_HAVE_CHAR16_T 0 # endif #endif So the problem is that your library is built with C++11 and your code using the library isn't. Not a GCC issue, and nothing to do with optimization flags. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [HarfBuzz] does graphite affect the c++ munging? Does -On? 2012-11-05 18:23 ` James Cloos 2012-11-05 18:34 ` Jonathan Wakely @ 2012-11-05 18:41 ` Jonathan Kew 1 sibling, 0 replies; 8+ messages in thread From: Jonathan Kew @ 2012-11-05 18:41 UTC (permalink / raw) To: James Cloos; +Cc: gcc-help, harfbuzz, Philipp Thomas On 5/11/12 18:15, James Cloos wrote: > [Background for the harfbuzz readers: > > hb fails to compile with icu 50_rc and gcc 4.7.2 with an inconsistancy > between what icu provides for LEFontInstance::mapCharsToGlyphs() and > that hb wants.] > FYI, https://bugs.webkit.org/show_bug.cgi?id=101179 discusses a similar-sounding issue. You might want to keep an eye on any developments there. JK ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-11-05 18:46 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-11-04 23:10 does graphite affect the c++ munging? Does -On? James Cloos 2012-11-05 0:32 ` Jonathan Wakely 2012-11-05 1:07 ` James Cloos 2012-11-05 3:11 ` Philipp Thomas 2012-11-05 18:23 ` James Cloos 2012-11-05 18:34 ` Jonathan Wakely 2012-11-05 18:46 ` Jonathan Wakely 2012-11-05 18:41 ` [HarfBuzz] " Jonathan Kew
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).