gcc links to wrong GLIBCXX version when O2 flag is specified - c++

Question

I have a shared library file which I build using a Makefile. I ran into an issue where, after building the library, I'd get the dreaded GLIBCXX_ not found linker error.
This case is particularly strange. When I compile with the -g3 flag, I don't get the error. If I compile with -O2, I get the error.
So, when I compile with -O2, and run ldd against the compiled .so file, I get:
$ ldd MYLIB.so.1
./MYLIB.so.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./MYLIB.so.1)
linux-vdso.so.1 => (0x00007fff21e8d000)
libz.so.1 => /lib64/libz.so.1 (0x00002b2cd4c40000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002b2cd4e54000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002b2cd5079000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b2cd529b000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b2cd54b7000)
libm.so.6 => /lib64/libm.so.6 (0x00002b2cd57b8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b2cd5a3b000)
libc.so.6 => /lib64/libc.so.6 (0x00002b2cd5c49000)
/lib64/ld-linux-x86-64.so.2 (0x0000003891400000)
So here, for some reason, /usr/lib64/libstdc++.so.6 is looking for GLIBCXX_3.4.9, which does not exist in /usr/lib64/libstdc++.so.6, as we can see using the strings utility:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_FORCE_NEW
So, to further investigate this, I run nm against the compiled .so file, and try to find what symbols are looking for GLIBCXX_3.4.9
$ nm --demangle MYLIB.so.1 | grep GLIBCXX_3.4.9
U std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long)##GLIBCXX_3.4.9
U std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)##GLIBCXX_3.4.9
Okay, so it looks like some standard C++ ostream code requires GLIBCXX_3.4.9. Okay... but it's only this one symbol that seems to require GLIBCXX_3.4.9. Everything else correctly links with GLIBCXX_3.4:
$nm --demangle MYLIB.so.1 | grep GLIBCXX
U std::string::find(char const*, unsigned long, unsigned long) const##GLIBCXX_3.4
U std::string::compare(char const*) const##GLIBCXX_3.4
U std::string::compare(std::string const&) const##GLIBCXX_3.4
U std::logic_error::what() const##GLIBCXX_3.4
U std::runtime_error::what() const##GLIBCXX_3.4
U std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::str() const##GLIBCXX_3.4
U std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()##GLIBCXX_3.4
... etc ...
So what could be the cause of this? Why would one particular symbol link GLIBCXX_3.4.9, but the rest don't? Even more strange - this only happens when I compile with -O2.
I'm pretty baffled by this. So, what are some likely reasons why this might occur? How does the linker/compiler chain determine which GLIBCXX version a particular symbol is found in?

Answer 1

This simply means you're compiling with a newer GCC than the /usr/lib64/libstdc++.so library belongs to, and you are not telling the dynamic linker how to find the right libstdc++.so
The reference to GLIBCXX_3.4.9 means you are compiling with at least GCC 4.2.0 but the system libstdc++.so is from an older version, 4.1.1 or 4.1.2.
The fact it's only a problem at -O2 is not really relevant, if you compile with a newer GCC you need to use its libstdc++.so, period. It seems that unless you compile with -O2 you don't actually get a hard dependency on the newer libstdc++.so but that's just chance, it could change if you make any small changes to your code that causes it to be optimised slightly differently.
You need to read https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths and https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic
Why would one particular symbol link GLIBCXX_3.4.9, but the rest don't?
Because the other symbols are unchanged between GCC 3.4 and 4.2 and the version of the symbol in your old libstdc++.so is the same as the one you linked against when building your executable.
The symbol that is not being found is something that was new in GCC 4.2, so it gets given a newer symbol version, and it can't be found in older libraries.