On 24 March 2016 at 15:16, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > On Thu, Mar 24, 2016 at 10:46 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >> 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. > > No, its not. I'm telling you this from first hand experience from reading it. > > My library does not have a problem; the issue is with with std::string > and std::list. So I'm trying to figure out how to do the things needed > to work with the updated std::string and std::list. You don't need to do anything to work with them (I can ddo literal reading too :-P) You only need to care if you want to work with both versions at once. > I perform literal reads, and I don't like to make leaps. As soon as I > leap, I'll be asked, "why the hell did you do that?". ABI_CHANGE is not a valid name for a non-standard macro defined by GCC, because it's not in the reserved namespace. >>>>> 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. > > OK, thanks. I was not aware I was supposed to do it twice myself. You > may be disappointed to hear, but until now, no one has told me to do > so. You were told here: https://gcc.gnu.org/ml/gcc-help/2016-03/msg00127.html (OK, it's a different thread, but it's the one that's specifically about how to do what we're now discussing in this thread). > This is what I have so far. Now, my question is, how can I automate it > so GCC builds both at once? Is there an option to have GCC do it for > me? No. That's why I said: 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.
