Why does -Wabi-tag complain when -std=c++03?

[Jonathan Wakely]

On 24 March 2016 at 15:16, Jeffrey Walton <noloader@gmail.com> wrote:
> On Thu, Mar 24, 2016 at 10:46 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 24 March 2016 at 14:36, Jeffrey Walton <noloader@gmail.com> wrote:
>>> On Thu, Mar 24, 2016 at 10:28 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>> On 24 March 2016 at 14:03, Jeffrey Walton <noloader@gmail.com> 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.