[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] libunistring-optional vs shared libgnu

From: Daiki Ueno
Subject: [bug-gettext] libunistring-optional vs shared libgnu
Date: Fri, 17 Jul 2015 17:20:55 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)


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 <address@hidden> 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:

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.

Daiki Ueno

reply via email to

[Prev in Thread] Current Thread [Next in Thread]