views:

235

answers:

2

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.

+6  A: 

C++ runtimes tend to be compiler specific and the library that you're looking for definitely is compiler version specific. Keep in mind that even if the interface doesn't change, the internals might.

You'll either need to acquire libraries built with the same compiler & library versions that you have, or install the appropriate compiler/library versions.

Timo Geusch
+1 and note that especially since the major version number of the library changed you would expect possibly breaking changes to be introduced.
Mark B
But both 3.4.9 and 4.1.2 have an SO number of 6. Doesn't that indicate the interface compatibility? Or am I way off there?
Chris Metzler
When the new symbols are added, they go to newly-created interfaces, so the program linked with a new version can clearly show that it needs an interface which exists only in the new version (in your case, GLIBCXX_3.4.9 interface). The program linked with an old library will continue to work with all newer versions with the same soname.
wRAR
wRAR -- but in this case, ld's not saying I need a newer library than the one I have; it's saying I need an *older* one. It's complaining that I need 3.4.9 when I have 4.1.2.Interestingly, when I use nm to look at the symbols in libstdc++ 4.1.2, I see GLIBCXX_3.4.n defined, where n=1-8; and the gcc homepage shows no v3.4.9 of gcc/glibc++ (they're bundled and versioned together, apparently) at http://gcc.gnu.org/releases.html. So I don't know what 3.4.9 even is.In the meantime, I've solved my practical problem by building GPSTk from source. But it bugs me that I don't understand this.
Chris Metzler
+1  A: 

Where did you get librxio.so.16.0? I think it's compiled with GCC > 4.1, and so it may not work with 4.1 runtime.

wRAR
It's part of the GPSTk package; they had a x86-64 binary dl available.At this point, I'm checking to see if the easiest solution isn't just to build their libraries from source using the compiler and libraries I've got.
Chris Metzler