Re: GCC 5 / libstdc++ abi wiki: can FIXMEs be fixed?
On 07/05/2015 08:52 PM, Steve M. Robbins wrote:
> I've heard rumours that GCC 5 is coming :-)
there are even rumours about GCC 6 (defaulting to C++14) ;)
> I help maintain several C++ libraries and expect some work is required to get
> through this GCC transition. I'd like to understand what I'm doing and do it
> right the first time. I'm just an average C++ programmer, not an avid follower
> of GCC nor even of debian lists. So below are lots of questions asked out of
> ignorance. Please don't shoot the messenger/questioner. :-)
> Posts here and bug reports reference the wiki page
> https://wiki.debian.org/GCC5 . I've read that page and there are a bunch of
> notes embedded within it that just confuse me:
> 1. "The good news is, that GCC 5 now provides a stable libcxx11 ABI, and
> stable support for C++11 (GCC version before 5 called this supported
> experimental). This required some changes in the libstdc++ ABI, and now
> libstdc++6 provides a dual ABI, the classic libcxx98 ABI, and the new libcxx11
> (FIXME: GCC 5 (<< 5.1.1-20) only provides the classic libcxx98 ABI)."
> What does the FIXME refer to? That the correct statement is "The good new is,
> that GCC 5 (post 5.1.1-20) now provides .."? Or something else?
removed, left over when I had no gcc-5 package in experimental.
> 2. "libstdc++ doesn't change the soname, provides a dual ABI. Existing C++98
> binary packages will continue to work. Building these packages using g++-5 is
> expected to work after build failures are fixed. FIXME: Will they only work
> when built with _GLIBCXX_USE_CXX11_ABI set to 0? By default they will use the
> new libstdc++ ABI."
> What's the answer to this FIXME? What does the last sentence mean? Does it
> mean that code built using g++5 by default uses the new libstdc++ ABI?
g++-5 in testing/unstable defaults to the cxx98 ABI (without any choice to use
the new ABI), g++-5 in experimental defaults to the new ABI (with the choice to
use the old one using -D_GLIBCXX_USE_CXX11_ABI=0).
> But if not rebuilt, existing code will use the existing libcxx98 ABI?
> The next
> paragraph says "GCC 6 is expected to change the c++ standard default ..." --
> but doesn't GCC 5 change the standard default already?
No. The compiler still defaults to the c++98 standard. Apparently the naming of
the ABI's is confusing, upstream now renamed it to "gcc4-compatible" and "new".
Whether this is better ... I don't know. GCC 5 now provides a libstdc++ which
conforms to the c++11 standard, and the implementation is supposed to provide a
> 3. "Library packages built using -std=c++0x or -std=c++11 may have an ABI
> change (unknown yet how many). How to find out about these?"
> What does this mean? Why would they have an ABI change? And how do we find
GCC upstream marked the c++11 as experimental in pre GCC 5 versions. There is no
guarantee that it worked in the past (however for the majority of transitions in
the past, it worked quiet well). I assume you'll only find out when something
goes wrong, and you see breakage. For applications, you probably won't notice
after the rebuild, for a library you may do a transition, changing the package name.
> 4. "If the library exports some symbols having either _cxx11 or B5cxx11 in the
> symbol name, it may be incompatible, if these are symbols which form part of
> the public API. To find out if these are part of the public API, you would need
> to build all reverse dependencies and see if any of these new symbols are
> Being pedantic: isn't that a signal of ABI (rather than API) change?
I didn't call that an API change. I'm just trying to describe where these ABI
changes are relevant to trigger a library transition.
> importantly: supposing my library does export some such symbols. Checking
> reverse deps in Debian is of course helpful: if any are referenced, then we
> know the interface changed.
this is my understanding.
> (or does it? what if the reverse-dep uses the
> symbol itself internally -- might this show a false-positive?)
It's not clear to me what you mean. If a library libfoo has a cxx11 symbol
defined, that is used by an app/reverse-dep, then it is not a false positive.
Just looking at the undefined symbols in the app without sorting out other cxx11
symbols coming from other libraries (e.g. from libstdc++) might lead to false
> But if none
> are found, can we conclude the interface has NOT changed? I wouldn't think
> so: it may simply be that the code in Debian simply doesn't exercise the
> relevant part of the interface. If that is the case: how then can one
> convince themself that there really is no change in interface?
your decision to make. If you think that this will make an ABI change, maybe ask
upstream, and/or change the library name.
> Additionally, there are some places where the text confuses me even without
> FIXME or README:
> * "Using different libstdc++ ABIs in the same object or in the same library is
> allowed, as long as you don't try to pass std::list to something expecting
> std::cxx11::list or vice versa. We should rebuild everything with g++-5 (once
> it is the default). Using g++-4.9 as a fallback won't be possible in many
> The first sentence doesn't seem connected to the second two sentences. What
> does "Using g++-4.9 as a fallback ..." mean? Why isn't it possible?
> What cases fail?
well, I gave the examples passing list as parameter.
PR66145 also is a case of an unwanted incompatibility.
> * In "Roadmap for libstdc++", it says "Depending on which libstdc++ ABI is
> configured as default ...".
> What is the plan now? Which ABI will be default?
see the first sentence of the paragraph. I clarified that the proposal is to do
the GCC defaults change and the ABI change in one step.
> * Section "libstdc++ c++11 incompatibilities (4.9 and 5)" has a short list of
> incompatibilities. Is this the complete list or just examples?
well, these are known incompatibilities. If you find more ...
> * "Passing std::list to something expecting std::cxx11::list or vice versa."
> Is this an incompatibility just regarding C++11 in 4.9 and 5? What if C++11
> code (built with GCC5) passes a list to an old library built using the
> libcxx98 ABI? Wouldn't that also fail?
yes, my understanding is that this will fail as well, although already when
trying to link that code.