Hello, This is a followup to my post sent to bug-gnulib in February. I came across a similar issue when building gettext 0.19.5 on Fedora.
Daiki Ueno <u...@gnu.org> writes: > LIBUNISTRING will be expanded to: > > LIBUNISTRING = /usr/lib64/libunistring.so -Wl,-rpath -Wl,/usr/lib64 > > and the following libtool link command reorders the input files: > > /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -o test-uninames \ > uniname/test-uninames.o ../gllib/libgnu.la /usr/lib64/libunistring.so \ > -Wl,-rpath -Wl,/usr/lib64 > > as: > > libtool: link: gcc -g -O2 -o test-uninames uniname/test-uninames.o \ > /usr/lib64/libunistring.so -Wl,-rpath -Wl,/usr/lib64 \ > ../gllib/.libs/libgnu.a -L/usr/lib64 -lunistring > > where libunistring.so is placed before libgnu.a. There is no problem if libgnu is statically linked to the program. However, in gettext, libgnu is created as a shared library (libgettextlib.so) and is dynamically linked to gettext tools (xgettext, msgfmt, etc) and the unit tests. In that case, the ordering of the library objects seems to matter. The work around is simple: make LIBUNISTRING=-lunistring, if one knows that an older libunistring is installed on the system: http://pkgs.fedoraproject.org/cgit/gettext.git/tree/gettext.spec#n232 But I think there should be a proper fix for this. Any suggestions? One idea is to create a separate static library which only consists of libunistring modules. Regards, -- Daiki Ueno
