升级版本冲突

Question

I have compiled boost::system and boost::serialization from with the older GCC ABI ( https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html ) due to some older third-party code I'm using.

I had them built to /usr/local/lib which is already set as a valid path to the linker (I use other libraries there as well), and renamed them to:

$ ls /usr/local/lib/libboost_*

/usr/local/lib/libboost_serialization_old_abi.so
/usr/local/lib/libboost_serialization_old_abi.so.1.60.0
/usr/local/lib/libboost_system_old_abi.so
/usr/local/lib/libboost_system_old_abi.so.1.60.0
/usr/local/lib/libboost_wserialization_old_abi.so
/usr/local/lib/libboost_wserialization_old_abi.so.1.60.0

Default, mainstream boost libraries are under /usr/lib as usual. What happens is that when I link any piece of code to these specific libraries with the custom flags -lboost_system_old_abi and -lboost_serialization_old_abi , the resulting binary will be linked to the default boost libraries :

$ ldd darwin_socket

linux-vdso.so.1 (0x00007ffd137ea000)
/usr/local/webots/resources/projects/robots/darwin-op/libraries/darwin/libdarwin.so (0x00007fcb9edaa000)
libipsocket.so.1 => /usr/local/lib/libipsocket.so.1 (0x00007fcb9eb7b000)
libboost_system.so.1.60.0 => /usr/lib/libboost_system.so.1.60.0 (0x00007fcb9e977000)
libboost_serialization.so.1.60.0 => /usr/lib/libboost_serialization.so.1.60.0 (0x00007fcb9e739000)
libController.so => not found
libCppController.so => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fcb9e3b7000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fcb9e0b2000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fcb9de9c000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fcb9dafb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcb9efc1000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fcb9d8f3000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fcb9d6d6000)

which is quite strange, because, if use original -lboost_system and -lboost_serialization flags, gcc can't even link to the default boost due to new/old ABI incompatibilities.

So what exactly is happening here?

Answer 1

The problem is that just renaming your custom built libraries is not enough. The library name is embedded into the library as soname (you can see it with the readelf -d command) and is used when your application is liked with the library. Basically, the sonames from the custom libraries are put as the dependencies into your application binary, and since they are the same as the official Boost library names, the wrong binaries are loaded in run time.

You have to make sure the custom built Boost libraries are properly named in the build process. You can try doing this by adding --buildid=old_abi option to your b2 command line.