does graphite affect the c++ munging? Does -On?

does graphite affect the c++ munging? Does -On?

[James Cloos]

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

Re: does graphite affect the c++ munging? Does -On?

[Jonathan Wakely]

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.

Re: does graphite affect the c++ munging? Does -On?

[James Cloos]

>>>>> "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

Re: does graphite affect the c++ munging? Does -On?

[Philipp Thomas]

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

Re: does graphite affect the c++ munging? Does -On?

[James Cloos]

[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

Re: does graphite affect the c++ munging? Does -On?

[Jonathan Wakely]

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.

Re: [HarfBuzz] does graphite affect the c++ munging? Does -On?

[Jonathan Kew]

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

Re: does graphite affect the c++ munging? Does -On?

[Jonathan Wakely]

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.