Question 38720 in Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Is there any potential problem I should be aware of when linking to dynamic libraries compiled by old version g++? – Ubuntu

There are dynamic libraries provided by others, which are out of my control. What I know is that most of the aforementioned libraries are compiled
by g++4.9.4 & g++4.8.4 with C++11 support, and few libraries are
compiled by g++11.1.0 with C++14 support. And I have to use newer g++ which supports C++17 to compile my project. I intend to use g++11.3.0 on Ubuntu20.4.

Is there any potential problem I should be aware of when linking to dynamic libraries compiled by the said old version g++?

Tags:

2

Answers


  1. 0

    TL;DR: the dynamic library linkage you describe should "just work", provided you link the executable using the newer version of g++.

    Both versions of GNU g++ you mention use libstdc++ (specifically libstdc++.so.6.0.*) to implement the support libraries needed for C++11/C++17.

    For the most part, newer versions of libstdc++ maintain what their ABI policy manual calls "forward compatibility":

    Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.

    There are a few caveats, for unusual cases (which are probably irrelevant to your situation):

    1. This assumes all the objects are built with compatible CPU ABI/architecture flags (i.e. -march, -mcpu, -m64, etc. if any), which is a general requirement for correctly linking libraries together (regardless of compiler version). The compiler defaults for these options should select compatible settings for your system, so this challenge usually only arises with cross-compilation scenarios where you’ve deliberately changed to a non-default ABI.
    2. The internal representation of some C++ library classes (eg std::string, std::list) have changed over time, which can lead to problems if two libraries are sharing access to the same C++ object. This should only be a problem if you pass C++ library objects or references to them across the library interface where the g++ version differs.
    Login or Signup to reply.
  2. 0

    Versions of gcc before 5.1 did not fully support C++11. They could not possibly. The ABI needed to support C++11 was not ready.

    See this article for more information.

    If you have object files compiled with gcc <5.1 and object files compiled with gcc >=5.1 (on default ABI settings), and they somehow share data that contain std::string and/or std::list objects, then they cannot work together. You need to recompile at least some of them.

    In many cases you will get linker errors, and in some other (rare) cases the program will compile, link, and have mysterious crashes at run time. You probably should not worry about these cases as they are unlikely to occur naturally with normal libraries.

    If there are no shared std::string or std::list involved, then you might be able to get away with it. However there are corner cases.

    If you have a shared library dynamically linked with libstdc++.5.x. and another one dynamically linked to libstdc++.6.x, the final executable will be indirectly linked with both. This could be a problem in some cases. Try LD_PRELOADing one or the other to establish precedence.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search