1

Having gone through a number of similar questions (see below), I don't think any of them cover this case.

Problem

Is it possible to dlopen and use a C++11 shared library compiled using gcc 4.9 from a C++03 application compiled with gcc 4.1? Both the library and application use libstdc++, including on the API (but not std::list, which is apparently a problem). I can't change the way the application is compiled (sadly), and must be certain that existing code doesn't break (e.g. if it ends up dynamically linking to a new version of libstdc++.so).

As far as I understand it (which is not very), on Linux the dynamic linker uses a flat namespace, meaning that is not possible to have the same symbol defined in two libraries. Does statically linking the library against the newer libstdc++ help at all here, or is there perhaps some other way?

Some similar questions that don't seem to answer this

Uri Granta
  • 1,814
  • 14
  • 25
  • I think GCC introduced an ABI break at version 5.1. Have you tried? – Guillaume Racicot Nov 15 '17 at 14:30
  • Tried what? Running the application against a newer version of libstdc++ (e.g. via LD_PRELOAD)? – Uri Granta Nov 15 '17 at 14:45
  • 1
    Linux shared objects support symbol versioning (https://gcc.gnu.org/wiki/SymbolVersioning), which I think should already apply to your situation. However some people argue, that versioned symbols introduce a whole different level of problems on their own (http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols). – datenwolf Nov 15 '17 at 21:41

2 Answers2

2

If you do that, you definitely need to use the newer libstdc++.so.6, which should be compatible with the system libstdc++.so.6 based on GCC 4.1 (in the sense that GCC upstream intends to preserve ABI compatibility for the library). It would be a very good idea to use the libstdc++.so.6 library that came with the GCC 4.9 compiler.

Once you do that, it is supposed to work, unless you hit the few of the compatibility gotchas you already listed, and as long as the C++ part of the library interface actually sticks to the C++98 subset and does not use any constructs which are not expressible in the language subset.

All this assumes that the library was actually compiled on the the system which uses GCC 4.1, which probably has something like glibc 2.5. If the library was compiled on a completely different, newer system, then you will likely run into library compatibility issues beyond libstdc++.so.6, and these libraries tend to be even harder to upgrade.

(There is also the possibility that the library was explicitly compiled for use with the 4.1-based system libstdc++.so.6 and everything just works, just as if by magic, but then you wouldn't be asking here, I suppose.)

Florian Weimer
  • 32,022
  • 3
  • 48
  • 92
1

If you still have problems there is the option to use a statically linked C-API library as border between the two, application and your library, see this post.

Also you may be able to explicitely demand an old version of a symbol, see this post

karsten
  • 639
  • 5
  • 13