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.
