14

I have a few static libraries, which I'm not the owner of, compiled with an old version of g++ 4.3.2 (c++11/c++0x not activated).

When I compile my code with g++ 4.6 (no c++11) and link it using g++ 4.6 with these static libraries, it links fine and I do not seem to get any issues at runtime (not tested everything though). I'm tempted to think that forward compatibility is OK.

Now I'd like to compile my code with gcc 4.8 with c++11 and still link it with those same, not recompiled static libraries.

Are ABI changes in g++ only an issue for linkage forward compatibility or can one get backward compatibility issues too?

Jonas Stein
  • 6,826
  • 7
  • 40
  • 72
Yohan Danvin
  • 885
  • 6
  • 13

2 Answers2

23

The G++ ABI for C++98 code is backward compatible, all the way back to GCC 3.4

So if you compile and link your final executable with GCC 4.8 you can link to objects and libraries built with anything from GCC 3.4 to 4.8 (but no newer)

The C++11 ABI is the same as the C++98 ABI and the standard library types that are common to both C++98 and C++11 have the same definitions, (ignoring GCC 4.7.0 and GCC 4.7.1, which had ABI incompatibilities in std::pair and std::list when using C++11, which have been fixed in 4.7.2 and later versions) so you can link C++98 and C++11 code together (unless the C++11 code was built with GCC 4.7.0 or 4.7.1)

However some C++11 library types are not stable yet and change between releases, e.g. because they were first shipped before the final C++11 standard and had to be changed to match the final rules. So it's not necessarily safe to mix C++11 code built with GCC 4.6 and C++11 code built with GCC 4.8

For your case, where all the C++11 code is built with GCC 4.8 that will be OK. If you upgrade the compiler you should rebuild all the C++11 code with the newer GCC to be safe. (You don't need to rebuild the C++98/C++03 code)

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • N.B. the last two paragraphs I've just added, which I should have made clear initially but was in a rush, sorry – Jonathan Wakely Apr 24 '13 at 22:16
  • Thank you for the precisions, Jonathan (oh right, **the** Johathan from ACCU 2013! Explains the quality answer :) – Yohan Danvin Apr 25 '13 at 09:19
  • I'm curious. How is ABI compatibility of say, `std::list`, maintained between C++98 and C++11, given the changes in requirements of the `size()` member? I always assumed it involved a new data member to store the size, which I would have naively expect to break ABI compatibility. – juanchopanza Oct 29 '14 at 08:51
  • 1
    @juanchopanza, you always get the same type in c++98 and c++11 modes. Whether the new data member is present is not affected by the language mode. When the new member is present there's a special attribute that alters the name mangling, so the new `std::list` and old `std::list` are distinct types. I'll be writing up documentation on this soon. (N.B. this only applies to GCC 5, no currently released version has O(1) `std::list::size()` anyway). – Jonathan Wakely Oct 29 '14 at 09:51
  • Thanks for the information. Interesting to find out about `std::list::size()`! Now, [this gcc wiki] mentions some potential incompatibility re. `std::list`, with a specific example for `clear()`. Does your comment above imply this information is out-dated? I haven't been able to reproduce BTW. – juanchopanza Oct 29 '14 at 13:20
  • 1
    @juanchopanza, that only applies to GCC 4.7.0 and 4.7.1, which are the only versions which add the _M_size member without changing the mangling. – Jonathan Wakely Oct 29 '14 at 13:27
  • Thanks again. Are the other issues mentioned here https://gcc.gnu.org/wiki/Cxx11AbiCompatibility resolved in g++4.8, or are they still something that one should be careful about? – juanchopanza Oct 29 '14 at 14:19
  • 1
    @juanchopanza, I've updated the wiki page now to give current info about the other issues – Jonathan Wakely Oct 29 '14 at 15:00
  • Thanks yet again. That's been extremely useful. – juanchopanza Oct 29 '14 at 15:11
  • I have a confusion about second line mentioning backward compatibility. in official documentation of GCC (https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html), we found this : "The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible." ! – Mohamed Hamzaoui Dec 07 '21 at 10:45
  • It's just different terminology, but I agree that part of the docs is a bit confusing. What I said above is consistent with the docs. The libstdc++ library is backwards compatible, which allows programs linked to it to be forwards compatible (meaning you can use a newer `libstdc++.so.6` with your old program). – Jonathan Wakely Dec 07 '21 at 20:04
0

The C++11 standard has as it's goal to maintain backwards compatibility, as does compiler vendors. As long as the library doesn't use anything that "breaks" C++11 standard, the library format itself should be the same.

See this for changes introduced in C++11.

So, presuming the code you are using to call the library (including headers), you should be fine.

Community
  • 1
  • 1
Mats Petersson
  • 126,704
  • 14
  • 140
  • 227