Reputation: 53
I 'm using gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 for the compile but I have also tried gcc 4.1.2 and I get the same error.
for gcc 5.2.1
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6|grep CXXABI gives
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_1.3.8
CXXABI_1.3.9
CXXABI_TM_1
CXXABI_FLOAT128
For the compiler being compiled gcc 4.8.3
strings gcc-build/build/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6|grep CXXABI
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_TM_1
CXXABI_1.3
CXXABI_1.3.2
CXXABI_1.3.6
CXXABI_1.3.1
CXXABI_1.3.5
CXXABI_1.3.4
CXXABI_TM_1
CXXABI_1.3.7
CXXABI_1.3.3
i.e no 1.3.8
prior to running configure and make I also tried:
export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:$LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH
../gcc-4.8.3/configure --build=x86_64-linux-gnu
make
Error message:
msgfmt -o fr.mo ../../../../gcc-4.8.3/libstdc++-v3/po/fr.po
msgfmt: gcc-build/build/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.55)
msgfmt: Makefile:460: recipe for target 'de.mo' failed
When compiling with gcc 4.1.2 I get the same error:
msgfmt -o fr.mo ../../../../libstdc++-v3/po/fr.po
gcc-build/gcc-4.8.3/build/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.55)
Makefile:460: recipe for target 'de.mo' failed
When compiling with gcc 4.1.2 i did the following prior to configure and make
#where libraries i have compiled with gcc 4.1.2 are located i.e
export LD_LIBRARY_PATH=/opt/devtools/gcc-4.1.2/lib
#where libstdc++.so.6 is
export LIBRARY_PATH=/opt/gcc-4.1.2/lib64
strings /opt/gcc-4.1.2/lib64/libstdc++.so.6|grep CXXABI
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.1
CXXABI_1.3
which makes me wonder where CXXABI_1.3.8 is coming from. I also did a 'make distclean' between changing compiler
Upvotes: 5
Views: 13924
Reputation: 11
just copy libstdc++.so
in system installed directory to your gcc source appropriate directory, remember to rename it properly.
attention: you may need to copy several times as during compiling, gcc will replace that library several times.
Upvotes: 0
Reputation: 2578
I had the same problem when I tried to build GCC 4.8.5 from source on Ubuntu 16.04.3 LTS with GCC 5.4.0.
As a workaround I just dropped LD_LIBRARY_PATH only for msgfmt command in makefiles. To be precise I give the exact commands I executed to get the build successful:
1 - extract the sources
tar zxfv gcc-4.8.5.tar.gz
cd gcc-4.8.5
2 - modify call of msgfmt (add LD_LIBRARY_PATH= ) and make sure it is correct
vi ./libstdc++-v3/po/Makefile.in
vi ./libstdc++-v3/po/Makefile.am
grep "MSGFMT =" ./libstdc++-v3/po/Makefile.in ./libstdc++-v3/po/Makefile.am
./libstdc++-v3/po/Makefile.in:MSGFMT = LD_LIBRARY_PATH= msgfmt
./libstdc++-v3/po/Makefile.am:MSGFMT = LD_LIBRARY_PATH= msgfmt
3 - configure (I restriced multilib to 64bit only, because I don't have libc6-dev-i386 installed on my 64bit host and don't want to do it only for this build), build and install
./configure --prefix=$HOME/gcc-4.8.5 --with-multilib-list=m64
make
make install
Upvotes: 7
Reputation: 730
I stumbled upon the same problem with a bit newer compiler combination, i.e. using gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 while building GCC 4.8.5. The solution worked out so far apparently did the job and gives valuable general explanation of the problem. I offer further details and an alternative solution below.
The error message in question comes from the msgfmt
program - part of gettext, an internationalization and localization system:
$ which msgfmt
/usr/bin/msgfmt
$ dpkg -S /usr/bin/msgfmt
gettext: /usr/bin/msgfmt
msgfmt
gets called by the GCC build system to compile messages emited by the C++ standard library (libstdc++) that is currently being built. msgfmt
is a dynamically linked executable, linked (among others) against libicuuc.so.55
- a cross-platform Unicode based globalization library:
$ ldd /usr/bin/msgfmt
libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007ff133f47000)
(other dependencies not shown for clarity)
The icuuc library is a dynamically linked shared object itself that depends on the stdc++ library:
$ ldd /usr/lib/x86_64-linux-gnu/libicuuc.so.55
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff688a16000)
(other dependencies not shown for clarity)
The above listing was generated using my interactive shell environment, which resolves the dependency on libstdc++.so.6
to the system-wide version of the C++ library located in /usr/lib/x86_64-linux-gnu
. However, the GCC build environment apparently resolves this dependency to the C++ library generated on the earlier stage of the current build process, i.e. to the one located in $TOP_BUILD_DIR/x86_64-linux-gnu/libstdc++-v3/src/.libs
- recall the originally posted error message:
msgfmt: gcc-build/build/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.55)
I get a fairly similar output:
msgfmt: /opt/build/gcc/gcc-4.8.4/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.55)
Now, answering the original question, the string 'CXXABI_1.3.8' comes from the libicuuc.so.55
library, which requires that the libstdc++.so.6
library it depends upon, provides a particular ABI version:
$ strings /usr/lib/x86_64-linux-gnu/libicuuc.so.55 | grep CXXABI
CXXABI_1.3.8
CXXABI_1.3
To summarize, the GCC build system creates a circular dependency, which mixes system-wide binaries with local libraries:
libstdc++ (currenlty built) > msgfmt > libicuuc.so.55 > libstdc++.so.6
by resolving libstdc++.so.6
to it's own library structure instead of the system-wide version.
The solution proposed by Mats Petersson, which involves rebuilding the libicuuc.so.55
library such that it depends on an older version of libstdc++.so.6
, which is (hopefully) compatible with the GCC build system, is certainly valid. However, it seems a bit unnatural for my taste, as it requires playing around with dependencies of a system-wide binary, which is out of control of any non-root user.
My alternative solution involves building the custom version of the gettext package instead, such that the msgfmt
binary is self-contained and its dependencies do not interfere with the GCC build system. It can be achieved by installing the custom version of gettext in /opt
and adjusting the relevant paths using environment modules.
Upvotes: 8
Reputation: 129524
So, this problem occurs when a library that has been built with a newer compiler is linked with an older version of C++ library - or sometimes when a newer headerfile is used to compile something that then links to an older C++ library.
It is also possible come up with a similar problem when moving binary files from one system to another, if the shared libraries installed on the "new system" are older than the ones on which the code was built.
There are typically three plausible solutions: 1. Recompile the offending library with an older compiler. 2. Install a newever version of the C++ library. 3. Rebuild the C++ library from sources (with a new enough compiler).
Upvotes: 4