Using shared libraries and mismatched compilers

Question

What are the chances using shared libraries that are compiled using different compiler versions than your program would introduce problems?

What if the language standard your programs use is different from their?

ie Could it be a problem if I link boost libraries compiled with gcc-4.8,c++11 while compiling my code with gcc-6,c++14, for instance?

Answer 1

Short answer, close to 100% that you'll have some issues unless the library was designed with this in mind. Boost was not designed with this in mind at all, it will not work.

Long answer, it might work under certain very specific circumstances (not for boost though). There are 2 main things that come into play:

• ABI compatibility
• Sub-library compatibility / inlined code

The ABI is the easy part. If eg compiler A mangles names differently than compiler B, it won't even link. Or if they have different calling conventions (eg how arguments are passed through registers/stack etc) then it might link but it will not work at all / crash in pretty obvious manners. Also most compilers on the same platform have the same calling conventions (or can be configured appropriately) so this shouldn't be a huge problem.

Sub-library compatibility and inlined code is trickier. For example, let's say that you have a library that passes out an allocated object, and it's the client's job to deallocate. If the library's allocator works differently from the one in the client, then this will cause problems (eg the library uses compiler A's new , and the main program uses compiler B's delete ).

Or there might be code in the headers (eg inline methods). The two compilers might compile them differently, which will cause issues.

Or the library might return a std::vector . The implementations of compiler A's vector might differ from compiler B's vector , so that won't work either.

Or there might be a struct or class passed around. The two compilers might not pack/pad them the same way, so they won't be laid out the same way in memory, and things will break.

So if the library is designed with this in mind, then it might work. Generally speaking that means that:

• All calls have to be extern C to avoid name mangling.
• No passing around of any externally defined structures (eg the STL)
• Even structs might cause issues unless the packing/padding is the same in both compilers
• Everything allocated by the library must also be deallocated by the library
• No throwing of exceptions (which is sort of implied by extern C )
• Probably a few more that I'm forgetting right now

Answer 2

If the ABI (and API) is the same, it will work fine, according to gcc.gnu.org's ABI Policy and Guidelines , "given an application compiled with a given compiler ABI and library API, it will work correctly with a Standard C++ Library created with the same constraints ."

A shared library compiled with a different ABI could work, but there are some cases of which to be aware because they could cause major bugs which would be incredibly difficult to detect.

gcc-4.8 and gcc-6 have different ABIs (Application Binary Interfaces), and so could output different compiled code in very specific cases, and cause an application to break.

However, " the GNU C++ compiler, g++, has a compiler command-line option to switch between various different C++ ABIs. " (According to ABI Policy and Guidelines.)

You can read more details about specific ABI issues from gcc.gnu.org :