bug-gettext
[Top][All Lists]
Advanced

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

Re: [bug-gettext] Static link fails with gettext 0.19.8.1


From: Bruno Haible
Subject: Re: [bug-gettext] Static link fails with gettext 0.19.8.1
Date: Tue, 14 Feb 2017 17:34:06 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-62-generic; KDE/5.18.0; x86_64; ; )

Hello,

Alexey Neyman wrote:
> A failure to link with libintl.a statically has been reported on the 
> crosstool-ng list:
> https://github.com/crosstool-ng/crosstool-ng/issues/597

The failure is, as you can see from

[ALL ] 
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libc.a(dcigettext.o):
 In function_nl_find_msg':
[ALL ] (.text+0x2b0): multiple definition of _nl_find_msg' 
[ALL ] 
/home/builder/crosstool-ng-github/output/arm-cortex-linux-gnueabi/buildtools/lib/libintl.a(dcigettext.o):/home/builder/crosstool-ng-github/output/src/gettext-0.19.8.1/gettext-tools/../gettext-runtime/intl/dcigettext.c:896:
 first defined here

a collision between libintl.a and libc.a.

The host triple 'x86_64-linux-gnu' indicates that it's a glibc system.
On glibc systems, you don't need libintl.a - it's all contained in glibc.

> The reason is again, multiple definitions of several symbols. libintl 
> was configured with:
>          --enable-static
>          --disable-shared
>          --disable-java
>          --disable-native-java
>          --disable-csharp
>          --without-emacs
>          --disable-openmp
>          --with-included-libxml
>          --with-included-gettext
>          --with-included-glib
>          --with-included-libcroco
>          --with-included-libunistring
>          --with-libncurses-prefix=/..../
>          --with-libiconv-prefix=/..../
>          --without-libpth-prefix

"./configure --help" says:
  --with-included-gettext use the GNU gettext library included here

This is the option that causes the collision.

> Patch attached.

Rejected. Use of --with-included-gettext on glibc systems is unsupported
because it makes no sense.

Btw, I find the idea of compiling statically, even for an embedded system,
outdated. We have seen large-scale internet damage recently due to security
flaws in IoT devices. The conclusion is clear: Even small devices, even IoT
devices, should have a mechanism to pull in security fixes. Deploying a
security fix is much easier on a system with shared libraries - if everything
is statically linked, you have to rebuild the entire system in order to
deploy a CVE fix.

Bruno




reply via email to

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