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.