If I compile a C++ program on my machine, and run it on another one (with older software) I get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
.
In fact on my system glibc is newer (I got gcc-libs 4.5.1: libstdc++.so.6.0.14) and strings /usr/lib/libstdc++.so.6 | grep GLIBCXX
prints from GLIBCXX_3.4
to GLIBCXX_3.4.14
. On the other system, instead, it only prints up to GLIBCXX_3.4.8
(I got libstdc++.so.6.0.8).
So I've got a few questions:
Why my linker links C++ binaries against libstdc++ version GLIBCXX_3.4.9
instead of GLIBCXX_3.4.14
?
If I complied my binary against libstdc++ version GLIBCXX_3.4
I guess it would run almost on everywhere. Would that imply any sort of issues? (eg: would it use older -and thus worse- algorithm implementations?)
If instead I statically link my program against my libstdc++ I guess it will run everywhere; the binary will be a lot bigger (~1MB) of course, any other pros/cons?
Can I force the linker to link my binary against a given version of libstdc++?
typically if you want to go newer than those, glibc will generally work with the version of gcc that was in development at the time of the release. e.g. glibc-2.23 was released 18 Feb 2016 and gcc-6 was under development at that time, so glibc-2.23 will work with gcc-4.7 through gcc-6.
Use readelf -a
and objdump -x
to inspect ELF files in preference to strings
.
Actually, all the GLIBCXX_* versions don't apply to the entire library, but to each symbol (symbol versioning, see DSO-howto). So you can have e.g: std::char_traits<wchar_t>::eq@@GLIBCXX_3.4.5
and std::ios_base::Init::~Init()@@GLIBCXX_3.4
on the same library file.
The fact that your program needs GLIBCXX_3.4.9 probably means that it has been linked against a symbol that has been introduced/has changed semantics on GLIBCXX_3.4.9.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With