Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc on Solaris x64

[suzuki toshiya]

Dear Kanazawa-san,

Hmm, it looks good... why Oracle cc hides all symbols...?

Regards,
mpsuzuki

Kiyoshi KANAZAWA wrote:
> Dear Suzuki san,
> 
> ftexport.sym is attached,
> 
> Regards,
> 
> --- Kiyoshi
> 
> 
> ----- Original Message -----
> From: suzuki toshiya <address@hidden>
> To: Kiyoshi KANAZAWA <address@hidden>
> Cc: "address@hidden" <address@hidden>
> Date: 2018/5/3, Thu 20:42
> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
> on Solaris x64
> 
> Dear Kanazawa-san,
> 
> Thank you for confirmation that the symbol loss occurs
> in linking phase.
> 
> Looking at make.log... GNU libtool receives the objs/ftexport.sym.
> 
> 124  ./builds/unix/libtool --mode=link cc -m64 \
>   -o /tmp/freetype-2.9.1/objs/libfreetype.la \
>   /tmp/freetype-2.9.1/objs/ftsystem.lo \
>   <snip> \
>   /tmp/freetype-2.9.1/objs/psnames.lo \
>   -rpath /usr/local/lib -version-info 22:1:16 \
>   -lz -lbz2 -L/usr/lib -lpng14 -no-undefined \
>   -export-symbols /tmp/freetype-2.9.1/objs/ftexport.sym
> 
> Then, GNU libtool makes "libfreetype.so.6.16.1.exp" which is
> a mapfile to contol the symbol exposure.
> 
> 125  libtool: link: echo "{ global:" \
>   > /tmp/freetype-2.9.1/objs/.libs/libfreetype.so.6.16.1.exp
> 126  libtool: link: cat /tmp/freetype-2.9.1/objs/ftexport.sym | \
>   /opt/local/amd64/bin/sed -e "s/\(.*\)/\1;/" \
>   >> /tmp/freetype-2.9.1/objs/.libs/libfreetype.so.6.16.1.exp
> 127  libtool: link: echo "local: *; };" \
>   >> /tmp/freetype-2.9.1/objs/.libs/libfreetype.so.6.16.1.exp
> 
> I think the mapfile generated by this command is almost same
> with that for GNU ld.
> 
> Then, it is passed to C compiler via "-M" option.
> 
> 128  libtool: link:  cc -m64 -G \
>   -z defs -M /tmp/freetype-2.9.1/objs/.libs/libfreetype.so.6.16.1.exp \
>   -h libfreetype.so.6 \
>   -o /tmp/freetype-2.9.1/objs/.libs/libfreetype.so.6.16.1 \
>   <snip>
>   /tmp/freetype-2.9.1/objs/.libs/psnames.o \
>   -lz -lbz2 -L/usr/lib -lpng14 -lc  -m64
> 
> About "-M" option, I can find the note around here:
>     https://docs.oracle.com/cd/E19253-01/819-0391/appendixb-45356/index.html
>     https://docs.oracle.com/cd/E19455-01/806-2734/6jbuas7tt/index.html
> 
> I'm afraid the syntax could be different from that for GNU ld.
> But, the usage of the mapfile ought to have been same
> in FreeType-2.9. So maybe I should check the content of the
> mapfile. Could you post the xz-compressed ftexport.sym?
> 
> Regards,
> mpsuzuki
> 
> Kiyoshi KANAZAWA wrote:
>> Dear Suzuki san,
>>
>> a) log files of configure & make are attached.
>>
>> b) You are right.
>> % nm objs/ftinit.o|grep FT_Init_FreeType
>> [32]    |                960|                123|FUNC |GLOB |2    |2      
>> |FT_Init_FreeType
>> % nm objs/.libs/ftinit.o|grep FT_Init_FreeType
>> [32]    |                960|                123|FUNC |GLOB |2    |2      
>> |FT_Init_FreeType
>> % nm objs/.libs/libfreetype.so.6.16.1|grep FT_Init_FreeType
>> [533]  |              349760|                123|FUNC |LOCL |2    |17    
>> |FT_Init_FreeType
>> Regards,
>>
>> --- Kiyoshi
>>
>>
>> ----- Original Message -----
>> From: suzuki toshiya <address@hidden<mailto:address@hidden>>
>> To: Kiyoshi KANAZAWA <address@hidden<mailto:address@hidden>>
>> Cc: "address@hidden<mailto:address@hidden>" 
>> <address@hidden<mailto:address@hidden>>
>> Date: 2018/5/3, Thu 19:05
>> Subject: Re: [ft-devel] [freetype-2.9.1] FT_Init_FreeType is missing with cc 
>> on Solaris x64
>>
>> Dear Kanazawa-san,
>>
>> Kiyoshi KANAZAWA wrote:
>>> a)
>>> freetype-2.9.1 ... objs/.libs/libfreetype.so.6.16.1
>>> freetype-2.9  ... objs/.libs/libfreetype.so.6.16.0
>>> Is this what you need ?
>> No, libfreetype.so.x.y.z is the resulted shared library, not the file to 
>> control
>> the symbols.
>> ahhh, my request was how ftexport.sym was processed during the linking.
>> In the case of gcc + GNU ld, ftexport.sym is converted to GNU ld script,
>> libfreetype.ver (conversion is done by GNU libtool).
>> Could you post the (xz-compressed) log of whole commands executed in the 
>> building?
>>
>>> b)
>>> It may be caused in cc phase, but not in ld.
>>> I once experienced the similar problem with "cc -fvisibility=hidden" on 
>>> Oracle cc.
>>>
>>> For example, generating ftsystem.o
>>> freetype-2.9.1:
>>> libtool: compile:  cc -m64 -I/tmp/freetype-2.9.1/objs -I./builds/unix 
>>> -I/tmp/freetype-2.9.1/include -c -g -fvisibility=hidden 
>>> -I/usr/include/libpng14 "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" 
>>> -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" 
>>> "-DFT_CONFIG_OPTIONS_H=<ftoption.h>" builds/unix/ftsystem.c  -KPIC -DPIC -o 
>>> /tmp/freetype-2.9.1/objs/.libs/ftsystem.o
>>>
>>> freetype-2.9:
>>> libtool: compile:  cc -m64 -I/tmp/freetype-2.9/objs -I./builds/unix 
>>> -I/tmp/freetype-2.9/include -c -g -I/usr/include/libpng14 
>>> "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY 
>>> "-DFT_CONFIG_MODULES_H=<ftmodule.h>" "-DFT_CONFIG_OPTIONS_H=<ftoption.h>" 
>>> builds/unix/ftsystem.c  -KPIC -DPIC -o 
>>> /tmp/freetype-2.9/objs/.libs/ftsystem.o
>> Basically, FreeType source inserts "__attribute__(( visibility("default") 
>> ))".
>> By this, although gcc compiles the objects with "-fvisibility=hidden", but 
>> the
>> public symbols are exported, like this.
>>
>> ...
>> 000000000000e022 t ft_trig_downscale
>> 000000000000e073 t ft_trig_prenorm
>> 000000000000e153 t ft_trig_pseudo_rotate
>> 000000000000e2cf t ft_trig_pseudo_polarize
>> 000000000000048e T FT_MulDiv
>> 000000000000010f T FT_Get_Advance
>> 0000000000000215 T FT_Get_Advances
>> 0000000000003212 T FT_Load_Glyph
>> ...
>>
>> Please post the result of "nm" command for an object file. If no global 
>> symbols
>> are found in it, maybe the effect of -fvisibility option might be different
>> between GCC and Oracle CC. If so, it would be reasonable to introduce the
>> exceptional handling for Oracle CC. But still I'm wondering whether it is in
>> compiling phase issue or linking phase issue.
>>
>>> Tried to remove "-fvisibility=hidden", but failed with the following patch.
>>> "-fvisibility=hidden" is still specified.
>>> Where should I change to test it ?
>> Do you want to use cmake in FreeType2? I don't recommend, it does not support
>> GNU libtool, so the platform-independent control for symbol exposure would be
>> poor. Also current cmake is contributed by the users, maybe tested on only 1 
>> or
>> 2 dominant platforms, I'm afraid nobody tested in on Solaris with Oracle
>> toolchain (and the contributors have no access to Solaris). Ah, looking at 
>> the
>> commands in above, you seem to be using autoconf. Thanks in advance!
>>
>>> === From here, patch I tried ===
>>> diff -ur ../freetype-2.9.1.orig/CMakeLists.txt ./CMakeLists.txt
>>> --- ../freetype-2.9.1.orig/CMakeLists.txt      2018-05-01 
>>> 19:45:45.000000000 +0000
>>> +++ ./CMakeLists.txt    2018-05-03 17:28:12.766516654 +0000
>>> @@ -337,7 +337,7 @@
>>>
>>>  set_target_properties(
>>>    freetype PROPERTIES
>>> -    C_VISIBILITY_PRESET hidden)
>>> +    C_VISIBILITY_PRESET default)
>>>
>>>  target_compile_definitions(
>>>    freetype PRIVATE FT2_BUILD_LIBRARY)
>> Hmm.
>>
>>> diff -ur ../freetype-2.9.1.orig/builds/unix/configure 
>>> ./builds/unix/configure
>>> --- ../freetype-2.9.1.orig/builds/unix/configure        2018-05-02 
>>> 06:34:47.000000000 +0000
>>> +++ ./builds/unix/configure    2018-05-03 17:27:54.382195684 +0000
>>> @@ -13416,7 +13416,9 @@
>>>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -fvisibility=hidden 
>>> compiler flag" >&5
>>>  $as_echo_n "checking for -fvisibility=hidden compiler flag... " >&6; }
>>>  orig_CFLAGS="${CFLAGS}"
>>> +#ifndef __SUNPRO_C
>>>  CFLAGS="${CFLAGS} -fvisibility=hidden"
>>> +#endif
>>>  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>>>  /* end confdefs.h.  */
>>> diff -ur ../freetype-2.9.1.orig/builds/unix/configure.ac 
>>> ./builds/unix/configure.ac
>>> --- ../freetype-2.9.1.orig/builds/unix/configure.ac    2018-05-02 
>>> 06:34:44.000000000 +0000
>>> +++ ./builds/unix/configure.ac  2018-05-03 17:27:54.382907980 +0000
>>> @@ -313,7 +313,9 @@
>>>  #
>>>  AC_MSG_CHECKING([for -fvisibility=hidden compiler flag])
>>>  orig_CFLAGS="${CFLAGS}"
>>> +#ifndef __SUNPRO_C
>>>  CFLAGS="${CFLAGS} -fvisibility=hidden"
>>> +#endif
>>>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
>>>                    AC_MSG_RESULT(yes),
>>>                    CFLAGS="${orig_CFLAGS}"
>>> diff -ur ../freetype-2.9.1.orig/builds/unix/configure.raw 
>>> ./builds/unix/configure.raw
>>> --- ../freetype-2.9.1.orig/builds/unix/configure.raw    2018-05-01 
>>> 19:35:09.000000000 +0000
>>> +++ ./builds/unix/configure.raw 2018-05-03 17:27:54.383361566 +0000
>>> @@ -313,7 +313,9 @@
>>>  #
>>>  AC_MSG_CHECKING([for -fvisibility=hidden compiler flag])
>>>  orig_CFLAGS="${CFLAGS}"
>>> +#ifndef __SUNPRO_C
>>>  CFLAGS="${CFLAGS} -fvisibility=hidden"
>>> +#endif
>>>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
>>>                    AC_MSG_RESULT(yes),
>>>                    CFLAGS="${orig_CFLAGS}"
>> Excuse me, these changes for autotools look quite different from the syntax 
>> of
>> autoconf, it looks like C preprocessor. Have you ever resolved similar 
>> problem
>> by such patch for autoconf files?
>>
>>
>>
> 
> 
>