Re: GCC version bikeshedding

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Aug 6, 2014 at 12:25 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 6 August 2014 11:20, Richard Biener wrote:
>> On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> On 6 August 2014 10:06, Jakub Jelinek wrote:
>>>> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
>>>>> > - libstdc++ ABI changes (it is a significant user visible change,
>>>>> >   if you rebuild everything, no extra effort is needed, but otherwise
>>>>> >   if you want some C++ code built with older compilers work together
>>>>> >   with code built with newer compilers, it might require source code
>>>>> >   changes (the abi_tag attribute additions where needed and warning
>>>>> >   suggest to put those at), at least that is my current understanding
>>>>> >   of the plans
>>>>>
>>>>> But that's only with -std=c++11?  Which had no compatibility
>>>>> guarantees before?
>>>>
>>>> No, AFAIK it is also -std=c++98.  At least my understanding was that
>>>> std::list and std::string are going to change ABI (and get new abi_tag)
>>>> in all C++ modes.  Jonathan/Jason/Paolo, is that right?
>>>
>>> Correct. We want C++03 code to continue to be able to interoperate
>>> with C++11 code.
>>>
>>> It's an ABI change for all modes (but not a SONAME change because the
>>> old and new definitions will both be present in the .so).
>>
>> Ugh.  That's going to be a nightmare to support.  Is there a configure
>> switch to change the default ABI used?
>
> You'll need to define a macro to get the old versions of the affected
> classes, we can add a configure switch to make that the default.
>
>>  That is, on a legacy system
>> can I upgrate to 5.0 and get code that interoperates fine with code
>> built with 4.8?  (including ABI boundaries using the affected classes?
>> I suspect APIs with std::string passing are _very_ common, not
>> sure about std::list)
>>
>> What's the failure mode the user will see when linking against a
>> 4.8 compiled library with a std::string interface using 5.0?
>
> There will be a linker error as the types and the interface functions
> will have different mangled names.

Ok, so the problematical case is

struct X { std::string s; };
void foo (X&);

then.  OTOH I remember that then mangling of X changes as well?

Is there a documented way to build a shared library with both
variants?  Or isn't there a good way to automate that?  Like
building the library objects twice once with the new and once
with the old ABI and then simply link both into the shared library?
(of course that doesn't work - but maybe use -ffunction-sections
-fdata-sections and then use the union of all sections discarding
duplicates?)

Richard.