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

[Jeffrey Walton <noloader at gmail dot com>]

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.

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?".

>>>> 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.

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?

$ cat test.cxx
#include <string>

std::string foo __attribute__ ((visibility ("default")));
std::string bar __attribute__ ((visibility ("default")));

$ g++ -D_GLIBCXX_USE_CXX11_ABI=0 -c test.cxx -o test-v1.o
$ g++ -D_GLIBCXX_USE_CXX11_ABI=1 -c test.cxx -o test-v2.o

$ ar cr test.a test-v1.o test-v2.o
$ ranlib test.a

$ g++ -shared test-v1.o test-v2.o -o test.so

$ nm test.a

test-v1.o:
00000004 B bar
         U __cxa_atexit
         U __dso_handle
00000000 B foo
0000006c t _GLOBAL__sub_I_foo
00000000 t _Z41__static_initialization_and_destruction_0ii
         U _ZNSsC1Ev
         U _ZNSsD1Ev

test-v2.o:
         U __cxa_atexit
         U __dso_handle
0000006c t _GLOBAL__sub_I__Z3fooB5cxx11
00000018 B _Z3barB5cxx11
00000000 B _Z3fooB5cxx11
00000000 t _Z41__static_initialization_and_destruction_0ii
         U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev
         U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev

$ nm test.so
00002020 B bar
00002018 B __bss_start
00002018 b completed.7181
         U __cxa_atexit@@GLIBC_2.1.3
         w __cxa_finalize@@GLIBC_2.1.3
00000650 t deregister_tm_clones
000006e0 t __do_global_dtors_aux
00001ef4 t __do_global_dtors_aux_fini_array_entry
00002014 d __dso_handle
00001efc d _DYNAMIC
00002018 D _edata
00002054 B _end
0000087c T _fini
0000201c B foo
00000730 t frame_dummy
00001ee8 t __frame_dummy_init_array_entry
00000980 r __FRAME_END__
00002000 d _GLOBAL_OFFSET_TABLE_
000007dc t _GLOBAL__sub_I_foo
00000862 t _GLOBAL__sub_I__Z3fooB5cxx11
         w __gmon_start__
000005e0 T _init
         w _ITM_deregisterTMCloneTable
         w _ITM_registerTMCloneTable
00001ef8 d __JCR_END__
00001ef8 d __JCR_LIST__
         w _Jv_RegisterClasses
00000690 t register_tm_clones
00002018 d __TMC_END__
00000640 t __x86.get_pc_thunk.bx
0000076c t __x86.get_pc_thunk.dx
0000203c B _Z3barB5cxx11
00002024 B _Z3fooB5cxx11
00000770 t _Z41__static_initialization_and_destruction_0ii
000007f6 t _Z41__static_initialization_and_destruction_0ii
         U _ZNSsC1Ev@@GLIBCXX_3.4
         U _ZNSsD1Ev@@GLIBCXX_3.4
         U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev@@GLIBCXX_3.4.21
         U _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@@GLIBCXX_3.4.21