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.