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 ?

CodePudding user response：

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.

TL;DR: the dynamic library linkage you describe should "just work", provided you link the executable using the newer version of g . Of course this assumes all the objects are built with compatible CPU ABI/architecture flags (i.e. -march, -mcpu, -m64, etc. if any), but that is probably irrelevant to your situation.

CodePudding user response：

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.