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

[Alexey Neyman]

On 02/14/2017 08:34 AM, Bruno Haible wrote:
> 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.
Ok, I'll disable building gettext for glibc hosts. Right now it is the 
same process for all systems that includes gettext.
> > 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.
Just to clarify, ct-ng is not building "an entire system", it builds 
just the toolchain (gcc, binutils + a few extras) and the distribution 
of that toolchain, at least to some people, is easier if statically 
compiled. The target of that toolchain may just as well support dynamic 
libraries, depending on the configuration.

So, installing a new toolchain with a fix is just upgrading a single 
package.

I admit it is possible that the toolchain's vendor may not be as quick 
in rebuilding the package as the major distributions. But on the other 
hand, toolchain doesn't run with elevated privileges nor does it handle 
any incoming connections.

Regards,
Alexey.