GCC version bikeshedding

[Marc Glisse]

On Wed, 6 Aug 2014, Jakub Jelinek wrote:

> On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
>> Ok, so the problematical case is
>>
>> struct X { std::string s; };
>> void foo (X&);
>
> Yeah.
>
>> then.  OTOH I remember that then mangling of X changes as well?
>
> Only if you add abi_tag attribute to X.

Note that -Wabi-tag can tell you where it is needed.

struct __attribute__((abi_tag("marc"))) X {};
struct Y { X x; };

a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in 
the type of 'Y::x') has [-Wabi-tag]
  struct Y { X x; };
         ^
a.cc:2:14: note: 'Y::x' declared here
  struct Y { X x; };
               ^
a.cc:1:41: note: 'X' declared here
  struct __attribute__((abi_tag("marc"))) X {};
                                          ^

> I hope the libstdc++ folks will add some macro which will
> include the right abi_tag attribute for the std::list/std::string
> cases, so you'd in the end just add
> #ifndef _GLIBCXX_ABI_TAG_SOMETHING
> #define _GLIBCXX_ABI_TAG_SOMETHING
> #endif
> ...
> struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
> void foo (X&);
> or similar.

So we only need to patch every project out there...


> A clean .so.7 break would be significantly worse nightmare.  We've been
> there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
> fewer C++ plugins etc. in packages and it still it was unsolvable.
> With the abi_tag stuff, you have the option to make stuff interoperable
> when mixing compiler, either with no effort at all, or some limited
> effort.  With .so.7, you have no option, nothing will be interoperable.

I disagree that it is worse, but you have more experience, I guess we
will see the results in a few years...

-- 
Marc Glisse