On 24 March 2016 at 14:36, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > On Thu, Mar 24, 2016 at 10:28 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >> On 24 March 2016 at 14:03, Jeffrey Walton <noloader@xxxxxxxxx> wrote: >>>>>> The new std::string and std::list are also valid implementations for C++03. >>>>> >>>>> OK, good. Thanks. >>>>> >>>>> If its a valid implementation, then why is the compiler complaining? >>>> >>>> That question doesn't even make sense. GCC's warnings aren't there to >>>> say "this implementation does not conform to the standard". >>> >>> Yeah, it only get worse: >>> >>> $ g++ -x c++ -include iostream -dM -E - </dev/null | grep ABI_CHANGE >>> $ g++ -x c++ -include iostream -std=c++11 -dM -E - </dev/null | grep ABI_CHANGE >>> $ >> >> What's this supposed to show? Worse than what? > > That it makes even less sense when trying to follow the blog post. > >> The ABI_CHANGE macro in the blog post is just an example of a macro >> that might appear in a third-party library, it's not defined by GCC. I >> thought the fact the example defines abi2::MyType made that fairly >> obvious. That isn't defined by GCC either. > > Actually, no, its not fairly obvious. If that was the intention, then > they only needed to state it. An example showing "abi2::MyType" is obviously not real code with real names. That's just common sense. >>> I get the problem its trying to solve; especially the part about the >>> return type ABI. But I have to admit I'm just about totally confused >>> about the implementation details for library authors, the coexisting >>> symbols discussed in the blog, and the ABI_CHANGE change macro. >> >> So don't try to support coexistence then, require users to use a build >> of your library that uses the same ABI as the rest of their libraries >> and objects. > > I'd _love_ to support coexistence so the problems go away for users. > That's kind of our duty here. We suffer the problem so users don't > have to. Is it? How many of your users download precompiled binaries, rather than either getting it from their distro or compiling it from source (both of which will usually mean the library is compiled with the same ABI as the rest of their code). > But for the life of me, I can't figure out how to get both symbols > included in the library and make coexitence work. Every time I try > something (like changing options) I get one set of symbols or the > other. I can't seem to get both of them in the library. See Marc's reply earlier in the thread. You compile the affected objects twice, once with the old ABI and once with the new ABI, and you link both into the library. That will almost certainly require some functions to be moved to different files, so that symbols which aren't affected don't end up multiply defined. There's nothing magic going on and no magic option to make it work. If you want your library to contain foo()[abi:cxx11] and foo() then you need to compile the function twice to produce both symbols and then link both symbols into the library.
