----- 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.htmlI'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>
> To: Kiyoshi KANAZAWA <
address@hidden>
> Cc: "
address@hidden" <
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?
>
>
>
ftexport.sym.xz