Isn't the C++ standard library backward-compatible?

[funkapus]

Hi. I'm working on a 64-bit Linux system, trying to build some code that depends on third-party libraries for which I have binaries. During linking, I get a stream of undefined reference errors for one of the libraries, indicating that the linker couldn't resolve references to standard C++ functions/classes, e.g.:

librxio.a(EphReader.o): In function `gpstk::EphReader::read_fic_data(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
EphReader.cpp:(.text+0x27c): undefined reference to `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)'
EphReader.cpp:(.text+0x4e8): undefined reference to `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)' 

I'm not really a C++ programmer, but this looks to me like it can't find the standard library. Doing some more research, I got the following when I looked at librxio's dependency for the standard library:

$ ldd librxio.so.16.0
./librxio.so.16.0: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./librxio.so.16.0)
   libm.so.6 => /lib64/libm.so.6 (0x00002aaaaad45000)
   libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaaafc8000)
   libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaab2c8000)
   libc.so.6 => /lib64/libc.so.6 (0x00002aaaab4d7000)
   /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) 

So I read that as saying that librxio (one of the third-party libraries) requires at least v3.4.9 of the standard library. But the version I have installed is 4.1.2:

$ rpm -qa | grep libstdc
compat-libstdc++-33-3.2.3-61.x86_64
libstdc++-devel-4.1.2-14.el5.i386
libstdc++-devel-4.1.2-14.el5.x86_64
libstdc++-4.1.2-14.el5.x86_64
libstdc++-4.1.2-14.el5.i386

Shouldn't this work? The shared object major number is 6, same as for v3.4.9. At this level, shouldn't this be backward compatible? It seems like the third-party library is looking for an earlier version of the standard library than what I have installed; but isn't there backward compatibility between versions with the same major number for the shared library? Again, I'm not really a C++ programmer; but I don't see what the problem is.

Any advice greatly appreciated. Thanks.

[Biju Scaria]

This is a dependency issue of stdc++ with glibc++. Your application is expecting that the libstdc++ linked with the 3.4.9 version of glibc. You will have to upgrade libc++ system wide or install latest version into a user directory and update your LD_LIBRARY_PATH. But be careful, you don't want to mess with it unless you know what you are doing.

[funkapus]

Hi, thanks. The point is that I've already got glibc++ version 4.1.2 installed; installing 3.4.9 would be a *downgrade*, not an upgrade. And I thought downgrading would never be necessary, because the c++ stdlib is backward-compatable. Is that not true?

Thanks.

[jsmith]

It is backwards compatible from a compilation standpoint, not from a runtime standpoint.

[funkapus]

jsmith: if I follow you, you're saying that even if the interface is the same, the effects of a function need not be the same, so you can't safely assume backward compatibility at runtime; and that makes sense to me. But I ran into problems at link-time.

My glibc++ v4.1.2 contains symbols for 3.4.1 through 3.4.8, so obviously it'd make sense that there'd be trouble if the library looks for symbol GLIBCXX_3.4.9. But what's weird is that I can't even find any reference to gcc/glibc++ v3.4.9 ever existing on the gcc site. So it seems odd for the third-party library to require that symbol.