Debian Buster 中的库不匹配？

Question

Note: all this work is being done on a closed network (ie no internet access).

I am being bitten by the GCC 5.0+ STL changes that occurred. It has been stated is other posts that starting in GCC 5.0 the Standard Template Libraries went through an update where there is now legacy stl and strict compliance stl. Code built with _GLIBCXX_USE_CXX11_ABI 1 does not link with code built with _GLIBCXX_USE_CXX11_ABI 0. A setting of 0 denotes legacy stl (ie std::string), whereas set to 1 constructs std::__cxx11::string.

OK fine that can be worked with if all user code is rebuilt to match the new libraries, but what if the debian packages are not built the same??? Now what?

Case in point, upgraded a Debian 8.11 (Jessie) system to 10.3 (Buster), included in the upgrade was Boost and Protobuf. Now build my software using the default _GLIBCXX_USE_CXX11_ABI 1 and get link errors with Protobuf because it appears Protobuf was built with either pre-gcc 5.0 or ABI set to 0. Boost has other issues that it cannot find some std::__cxx1112::string (saw this once) or just std::string.

Downloaded the source for Boost, transferred to closed network, and built using ABI 1, my code now links to boost but still fails the link to protobuf. Built Boost and my code with ABI 0, now link is successful with both.

Still in the process of getting a new mirror of Buster to determine if that will resolve, however the version I do have has mismatched libraries (incompatible)

This is just a warning that not all may be as it seems.

Boost went from 1_55 to 1_67, protobuf 9 to 17, gcc 4.8 to 8. Furthermore as of the writing of this post Glassfish is not compatible with the Buster version of JDK.

Answer 1

I was also at the question leading up to this one.

I'll pick a few points to address:

OK fine that can be worked with if all user code is rebuilt to match the new libraries

Indeed

but what if the debian packages are not built the same??? Now what?

That's not typically what happens. Debian's QA and build servers are very highly controlled, and situations like this cannot arise unless someone slips up really badly - and even then it would immediately be noticed in testing unless the package has no users.

[...] get link errors with Protobuf because it appears Protobuf was built with either pre-gcc 5.0 or ABI set to 0 [...]

If you seem to be in this situation still, we can do some analysis like in my former answer, but this time for libprotobufX. What could be happening is

• you have rogue (non-distro) shared libraries in your library path(s) (check ldconfig , LD_LIBRARY_PATH, -L flags)

  Alternatively on a succesful link (so with the workaround) check with ldd on your linked binaries that it loads libprotobufXXX.so from the expected location. If there's an unexpected location, there may be

  • an ldconfig location as mentioned above

  • there may be RPATH / RUNPATH entries baked into the ELF image by the linker (look for -Wl,rpath or similar in your build scripts). To inspect the binary to confirm this:

     objdump -x binary-or-library |grep RPATH objdump -x binary-or-library |grep RUNPATH

• your upgrade might not have successfully updated that package (check the upgrade process for errors, the status of your repo-mirror)

• you have a non-Debian (or non-supported) apt sources list (check /etc/apt/sources.list , /etc/apt/sources.list.d/*.list ) - those builds may not uphold the same level of distro consistency

  Sideline, usually canonical launchpad PPAs tend to reuse the distro build infrastructure so I think they're usually fine as long as the distro/component entries match your installation

  Alternatively, you can inspect the contents of the APT caches after a full apt-get update using eg

   apt-cache show libprotobuf.*

  Incidentally this will also give you the maintainers and contact addresses in case you do find a problem with the package. (There might be bug trackers better suited for this, I'm not known in this territory)

Hope this helps you find a lead

---

Still in the process of getting a new mirror of Buster to determine if that will resolve

That sounds like a good step

however the version I do have has mismatched libraries (incompatible)

I'm not sure what that means

Boost went from 1_55 to 1_67, protobuf 9 to 17, gcc 4.8 to 8. Furthermore as of the writing of this post Glassfish is not compatible with the Buster version of JDK.

Whoa, these are big jumps. If JDK is an issue, IME it helps to install a Java 8 or 9 JDK/JRE and make it the default, eg

$ update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).
  Selection    Path                                            Priority   Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      manual mode
* 2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode