17

As a downstream maintainer in a Linux distribution, some of the packages that I usually maintain are starting to use the C++11 features in their code base. All of them depend on different libraries packaged by the Linux distributions.

Problems with the ABI could appear when mixing C++11 code with C++98 and AFAIK, most of the current major Linux Distributions are not enabling the C++11 flag by default when compiling software to generate packages.

The question is: How are the major Linux distributions handling the entry of C++11 code? Is there a decent way of checking or avoiding these problems with the ABI when using system libraries?

Thanks.

Jose Luis Rivero
  • 171
  • 2
  • 8
    could you provide a reference about "most of the current major Linux Distributions are not enabling the C++11 flag" ? – DRC Dec 01 '14 at 18:36
  • 1
    are you mixing g++ versions? If not I believe this issue was fixed in GCC 4.8 – Mgetz Dec 01 '14 at 19:25
  • @Mgetz 4.8.1 still has at least one mentioned issue, and 4.8.2 has a few really minor ones mentioned. – Yakk - Adam Nevraumont Dec 01 '14 at 19:54
  • @Yakk any hope this was fixed in 4.9+ then? Or is this going to have to wait until 5.0? – Mgetz Dec 01 '14 at 19:57
  • @Mgetz I suspect it would get worse when `std::list` compliance occurs. The issues remaining in 4.8.2 in the link look really minor (exporting `vector::data()`, `istreambuf_iterator::reference`, exporting the result of a subtracted reverse iterator with a broken underlying iterator). – Yakk - Adam Nevraumont Dec 01 '14 at 20:01
  • @Yakk wouldn't C++98 code compiled with a C++11 compliant `std::list`, just use the C++11 list behavior? That would still be compliant with C++98 last I checked. – Mgetz Dec 01 '14 at 20:04
  • @Mgetz A problem is that a C++98 compiled library linking with a C++11 library compiled `std::list` will disagree about the size and layout of `std::list`, rendering them incompatible. – Yakk - Adam Nevraumont Dec 01 '14 at 21:10
  • @Yakk: Bullshit. That would only occur if the maintainer of that specific library decided to change his binary layout, which is far from guaranteed. For example, `std::list` can offer O(1) time in C++98 too. – Puppy Dec 01 '14 at 21:15
  • @Puppy That is exactly what happened in gcc 4.7.1. The existing gcc `std` uses an O(n) `size()` and a `std::list` that lacks a size field, which means if they become C++11 compliant they will have to break binary compatibility. – Yakk - Adam Nevraumont Dec 01 '14 at 21:30
  • @Yakk: Which they undid as fast as humanly possible. – Puppy Dec 01 '14 at 21:32
  • 2
    @Puppy have you seen the example Yakk was referring to? Maybe you should ask for it, instead of calling it BS because "nothing necessitates it". Nothing necessitates it. Yet it is allowed to happen. (On a practical level there's reality. Whether the standard wants it or not) – sehe Dec 01 '14 at 21:32
  • There is no difference between compiling GCC 4.7.1's std::list with -std=c++11 and -std=c++98. You're just as broken. Unless they decided to only break if you're compiling in C++11 mode, which is still their decision. You only suffer increased breakage with C++11 if a library vendor made it that way. – Puppy Dec 01 '14 at 21:34
  • 1
    That's assuming there's only that "accident". As there is no standards governing ABI and ABI interoperability, I'm not sure how a authoritative answer would come about. I'm pretty sure it needs more than "compiler devs would never do that, no?!" – sehe Dec 01 '14 at 21:36
  • I guess you've never heard of Itanium ABI? There is very definitely an ABI Standard. And it is definitely backwards compatible. It's no accident that GCC and Clang are almost completely binary compatible, nor that they are so across virtually every version (disregarding GCC's oops and non-Itanium platforms like Windows). – Puppy Dec 01 '14 at 21:38
  • @DRC about the C++11 flag in major distros, I meant: the compiler flag is not enabled by default for all the software at the moment of generating packages. For references, I would say: do we have any documenting that C++11 flag is on when compiling software? – Jose Luis Rivero Dec 02 '14 at 15:49

1 Answers1

3

The issue has nothing to do with C++11 vs C++98 except that C++11 can motivate binary changes. There is nothing special about binary changes motivated by C++11. They are just as breaking or non-breaking as regular binary changes. Furthermore, they are only changed if the library maintainer specifically chooses to change his binary interface.

In other words, this has nothing to do with the Standard version and everything to do with the library, unless the library explicitly chooses to offer two different binary interfaces to different Standard versions (which is still a library choice). Excepting this case, you are just as broken in C++98 as you are in C++11. Itanium is backwards compatible between the C++11-supporting versions and the C++98-supporting versions, so the compiler ABIs are not broken.

From memory, unless you're using 4.7.0 which they broke for fun and then unbroke, you're pretty much safe with libstdc++- they are storing up ABI breakage for a future release when they can make one big break.

In other words, whilst the transition period to C++11 can introduce additional motivation to break ABI and therefore additional risk, actually using C++11 itself does not introduce any additional risk.

Puppy
  • 144,682
  • 38
  • 256
  • 465