41

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:

  1. Why my linker links C++ binaries against libstdc++ version GLIBCXX_3.4.9 instead of GLIBCXX_3.4.14?

  2. 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?)

  3. 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?

  4. Can I force the linker to link my binary against a given version of libstdc++?

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
peoro
  • 25,562
  • 20
  • 98
  • 150

3 Answers3

39

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.

ninjalj
  • 42,493
  • 9
  • 106
  • 148
1
  1. That the the library version that is installed on your system. You could manually build the glibc version 3.4.14 and link to it
  2. That depends. Maybe the later version fixed some issues. The users of your program would have to link against the version that your program requires
  3. The memory usage is higher
  4. Yes, pass proper parameter to the linker. If you need specific version of the library, then it is best to download it, and build it manually, and link to it.

EDIT

I just remembered that statically linked libraries increase the memory usage.

BЈовић
  • 62,405
  • 41
  • 173
  • 273
  • @Ignacio Vazquez-Abrams So, I got 2 out of 4. For 1), I guess it is missing dependencies for the glibc. If 3 is not correct, I guess I live in ignorance. So, how to correct those two? – BЈовић Nov 09 '10 at 12:59
  • 1 I'm not certain of, but the library does have `GLIBCXX_3.4.14` *in it*, it's just not using it for some reason. For 3, consider the implications of not being able to update the library. – Ignacio Vazquez-Abrams Nov 09 '10 at 13:01
  • If you statically link the library, then you do not care to update it. All symbols are there. Updating the application is worse, because it is going to be larger – BЈовић Nov 09 '10 at 13:24
  • 1. I've got only libstdc++.so.6.0.14 installed. Besides ninjalj's answer is giving a different explaination... 4. What would be the proper parameter? – peoro Nov 09 '10 at 13:41
  • Same as linking other static libraries - pass it as a parameter when linking. http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html – BЈовић Nov 09 '10 at 15:02
-1

In my opinion, if your binaries don't use the new features of newer GLIBCXX version, then they won't be linked with that version. So your binaries was linked with GLBCXX 3.4.9, there must be at least one symbol exported from it, and there're no any symbols exported from version newer than 3.4.9.

Lewis Chan
  • 695
  • 6
  • 18