Mixing libstdc ++ versions

Question

There are 2 development teams developing C ++ applications for the same OS (Scientific Linux 6.5):

Team_A uses the provided OS compiler and libraries (GCC 4.4.7, GLIBC_2.12, GLIBCXX_3.4.13) to create their application in C ++ 98 and various shared libraries.

Team_B uses the new version of GCC (4.8.3), which was built from the source. This is a native compiler, it is associated with the libc OS and uses standard OS headers, but has its own version of stdC ++ (GLIBCXX_3.4.19). Team_B uses this compiler in C ++ 11 mode to create its own application ( AppB ) and deploys libstdC ++ and libgcc_s with it.

Team_A provides Team_B services as a shared library (.so, .hpp): LibA . The library API is a set of C ++ classes (declaration in the header, implementation in .so), and the methods take std :: string and other stdC ++ classes as arguments.

At this point, we come to the problem: AppB creates GLIBCXX_3.4.19 C ++ 11 style std :: any objects and passes them to LibA, which interprets them as GLIBCXX_3.4.13 C ++ 98 style objects, and this may not be compatible with the transition.

This is problem? Could this lead to a crash of the application? Are std :: any implementations compatible between versions (same memory layout)? What about C ++ 98 vs C ++ 11?

Some plot twists that bother me:

• AFAICT, when AppB runs only one downloadable libstdC ++ there, a new one. Even if LibA contacts older ones, it will not load.
• But the characters in libstdc ++ are versioned. So, if LibA explicitly uses an older version of the character, that will be associated with it. This means 2 different implementations of the same function will be used by AppB and LibA.
• std :: string and template classes containing templates, this means part of their implementation ends where it is generated, part of it in libstdC ++. So. Even if the new libstdC ++ is loaded, the generated template code in LibA is from the old version.

I would like to understand what exactly happens in this case, if it is risky and emptiness. Getting teams in one development environment is not an option. Removing std :: classes from the API will also be very difficult to do.

Any pointers are welcome! :)

Answer 1

Unlike C, there is no specific ABI for C ++. It means...

• C ++ mangling can change wikipedia: name mangling . Notice how the alpha name has changed.
• The structure of the class may be different. There may be different solutions for placing parts of the protected: private: and public: structure. The location and value of vtable can be moved between compilers. Different compiler versions may have different predefined functions, such as typeinfo in the vtable.
• The implementation of the structure in STL may be different between versions of C ++ (for example, line separation was performed in earlier versions of Visual Studio, but was prohibited in C ++ 11).
• On Windows, different runtimes can manage their memory in different ways (bind to another malloc / free). When passing complete objects or pointers, this can lead to a call to an incorrect free implementation.

What can you do to alleviate these problems?

Source Sharing

Instead of providing a compiled library, deliver services as source code to compile in the same environment.

Standardize on libstdc ++

The original built-in compiler can be rebuilt using the old stdC ++. This would limit the impact of paragraph 3).

Create facade

There is an interface between the two teams, which should speak a common language. This language should probably be C.

Team A => C ++ facade / stub => C interface => C ++ facade / proxy => Team B.

The facade should be built in the environment in which it will be used.