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.9instead ofGLIBCXX_3.4.14?If I complied my binary against libstdc++ version
GLIBCXX_3.4I 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++?
Answer
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.