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
