libstdc++ c++98 & c++11 ABI incompatibility

libstdc++ c++98 & c++11 ABI incompatibility

[Matthias Klose]

While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible, when built in c++98 and
c++11 mode.  Currently seen in libsigc++ (Signal Framework
for C++) and libapt-pkg (Debian package management).

sigc++/signal_base.h:

struct SIGC_API signal_impl
{
  typedef size_t size_type;
  typedef std::list<slot_base> slot_list;
  typedef slot_list::iterator       iterator_type;
  typedef slot_list::const_iterator const_iterator_type;

  signal_impl();
[...]

apt-pkg/error.h:

class GlobalError
{
[...]
        std::list<Item> Messages;
        bool PendingFlag;

Inline-ing code accessing these members gets the offset wrong.
For apt this probably can be changed so that it works in both
modes, but it gets more difficult for software which is not
controlled by the distribution like libsigc++.  I'll check
the archive for more occurrences of such code.

Looking at the build logs for packages built by a distribution,
I see that a lot of packages already build in c++0x/c++11 mode,
while the majority still uses the c++98 default. The GCC
documentation says "Support for C++11 is still experimental,
and may change in incompatible ways in future releases",
however upstream authors already use it by default (e.g.
LibreOffice).

So what could be done for a distribution?

 - For this particular issue, ask upstreams to work around this
   particular incompatibility.  This might work better, if the
   upstream sits "closer" to the distribution, but doesn't seem
   to be a general solution.

 - Identify all libraries with this incompatibility, and build
   the library twice for each mode. That would need a new soname
   when built in c++11 mode (which better should be done upstream
   first), and some logic to link with the c++11 library when
   building in c++11 mode.  But I don't think that distributions
   want to build and maintain a second c++ stack.

 - Build all packages in c++98 mode or in c++11 mode.  Because
   c++11 is still experimental, this would be c++98 mode.  But
   then c++11-only software would need removal from the
   distribution if a dependent library is only available in c++98
   mode. Or an internal copy of a library could be built in
   c++11 mode.

I currently tend to the latter approach, but would like to get
some feedback about other alternatives.

And is there a way to tell which mode a shared object/an
executable was built for, when just looking at the stripped
or unstripped object?

  Matthias

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jason Merrill]

On 06/14/2012 06:14 AM, Matthias Klose wrote:
> While PR53646 claims that c++98 and c++11 should be ABI
> compatible (modulo bugs), the addition of the _M_size member
> to std::_List_base::_List_impl makes libraries using
> std::list in headers incompatible, when built in c++98 and
> c++11 mode.

So it does.  That change should not have gone into 4.7 without having a 
plan to deal with the consequences.  I thought we weren't going to mess 
with ABI-breaking changes like this yet...

Jason

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jonathan Wakely]

On 14 June 2012 14:14, Matthias Klose wrote:
> So what could be done for a distribution?
>
>  - For this particular issue, ask upstreams to work around this
>   particular incompatibility.  This might work better, if the
>   upstream sits "closer" to the distribution, but doesn't seem
>   to be a general solution.
>
>  - Identify all libraries with this incompatibility, and build
>   the library twice for each mode. That would need a new soname
>   when built in c++11 mode (which better should be done upstream
>   first), and some logic to link with the c++11 library when
>   building in c++11 mode.  But I don't think that distributions
>   want to build and maintain a second c++ stack.

Or bump the libstdc++ soname and add the size member to std::list in
c++98 mode too.

I don't see that being a popular choice yet, but it is likely to
happen eventually.

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Michael Meeks]

On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
> While PR53646 claims that c++98 and c++11 should be ABI
> compatible (modulo bugs), the addition of the _M_size member
> to std::_List_base::_List_impl makes libraries using
> std::list in headers incompatible

	This is pretty nasty for LibreOffice (and no doubt others). We can, and
often do depend on rather a number of system C++ libraries and at a very
minimum, having no simple way to detect which C++ ABI we have to build
against 'old' vs. 'new' - is profoundly unpleasant.

	Is there no chance of having a bug fix that is a revision of the
(unintended?) ABI breakage in this compiler series ?

> And is there a way to tell which mode a shared object/an
> executable was built for, when just looking at the stripped
> or unstripped object?

	I guess here we have a compile-time checking problem; we would need
some more or less gross configure hack to try to detect which ABI is
deployed; suggestions appreciated.

	Many thanks for the (otherwise) excellent gcc :-)

	ATB,

		Michael.	

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jeff Law]

On 07/02/2012 10:26 AM, Michael Meeks wrote:
>
> On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
>> While PR53646 claims that c++98 and c++11 should be ABI
>> compatible (modulo bugs), the addition of the _M_size member
>> to std::_List_base::_List_impl makes libraries using
>> std::list in headers incompatible
>
> 	This is pretty nasty for LibreOffice (and no doubt others). We can, and
> often do depend on rather a number of system C++ libraries and at a very
> minimum, having no simple way to detect which C++ ABI we have to build
> against 'old' vs. 'new' - is profoundly unpleasant.
>
> 	Is there no chance of having a bug fix that is a revision of the
> (unintended?) ABI breakage in this compiler series ?
That's the direction I'd prefer to see (reversion until we're ready to 
make the wholesale ABI changes).  Not sure what the libstdc++ 
maintainers are thinking right now.

Jeff

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jonathan Wakely]

On 2 July 2012 17:43, Jeff Law <law@redhat.com> wrote:
> On 07/02/2012 10:26 AM, Michael Meeks wrote:
>>
>>
>> On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
>>>
>>> While PR53646 claims that c++98 and c++11 should be ABI
>>> compatible (modulo bugs), the addition of the _M_size member
>>> to std::_List_base::_List_impl makes libraries using
>>> std::list in headers incompatible
>>
>>
>>         This is pretty nasty for LibreOffice (and no doubt others). We
>> can, and
>> often do depend on rather a number of system C++ libraries and at a very
>> minimum, having no simple way to detect which C++ ABI we have to build
>> against 'old' vs. 'new' - is profoundly unpleasant.
>>
>>         Is there no chance of having a bug fix that is a revision of the
>> (unintended?) ABI breakage in this compiler series ?
>
> That's the direction I'd prefer to see (reversion until we're ready to make
> the wholesale ABI changes).  Not sure what the libstdc++ maintainers are
> thinking right now.

I'm wondering why the libstdc++ list was taken out of the CC list ;-)

I don't know what the others think but rather than just reverting it
I'd like to see inline namespaces used so that in C++11 mode std::list
refers to (for example) std::__2011::list, which has the additional
member.  That wouldn't link to C++03's std::list.

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Richard Guenther]

On Mon, Jul 2, 2012 at 7:00 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 2 July 2012 17:43, Jeff Law <law@redhat.com> wrote:
>> On 07/02/2012 10:26 AM, Michael Meeks wrote:
>>>
>>>
>>> On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
>>>>
>>>> While PR53646 claims that c++98 and c++11 should be ABI
>>>> compatible (modulo bugs), the addition of the _M_size member
>>>> to std::_List_base::_List_impl makes libraries using
>>>> std::list in headers incompatible
>>>
>>>
>>>         This is pretty nasty for LibreOffice (and no doubt others). We
>>> can, and
>>> often do depend on rather a number of system C++ libraries and at a very
>>> minimum, having no simple way to detect which C++ ABI we have to build
>>> against 'old' vs. 'new' - is profoundly unpleasant.
>>>
>>>         Is there no chance of having a bug fix that is a revision of the
>>> (unintended?) ABI breakage in this compiler series ?
>>
>> That's the direction I'd prefer to see (reversion until we're ready to make
>> the wholesale ABI changes).  Not sure what the libstdc++ maintainers are
>> thinking right now.
>
> I'm wondering why the libstdc++ list was taken out of the CC list ;-)
>
> I don't know what the others think but rather than just reverting it

From a RM point of view please go ahead and revert unintended ABI
breakage on all affected branches.  Add an entry to the respective
changes file to warn users about the incompatibility present on branches.

> I'd like to see inline namespaces used so that in C++11 mode std::list
> refers to (for example) std::__2011::list, which has the additional
> member.  That wouldn't link to C++03's std::list.

That means that C++03 std::list cannot interface with C++11 std::list
even within the v6 ABI, right?  That sounds not very much better
than the broken ABI we have right now (unless you suggest people
that want the C++11 std::list would have to use std::__2011::list and
otherwise would get the C++03 std::list even with -std=c++11?).

Richard.

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jonathan Wakely]

On 2 July 2012 18:24, Richard Guenther wrote:
> On Mon, Jul 2, 2012 at 7:00 PM, Jonathan Wakely wrote:
>> I'd like to see inline namespaces used so that in C++11 mode std::list
>> refers to (for example) std::__2011::list, which has the additional
>> member.  That wouldn't link to C++03's std::list.
>
> That means that C++03 std::list cannot interface with C++11 std::list
> even within the v6 ABI, right?

Right.

>  That sounds not very much better
> than the broken ABI we have right now (unless you suggest people
> that want the C++11 std::list would have to use std::__2011::list and
> otherwise would get the C++03 std::list even with -std=c++11?).

No, I mean that with -std=c++11 there would be no 'list' declared in
namespace std. The name 'std::list' would refer to the 'list' in the
inline namespace 'std::__2011' which would be mangled differently.

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Paolo Carlini]

Hi,

On 07/02/2012 07:24 PM, Richard Guenther wrote:
> On Mon, Jul 2, 2012 at 7:00 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 2 July 2012 17:43, Jeff Law <law@redhat.com> wrote:
>>> On 07/02/2012 10:26 AM, Michael Meeks wrote:
>>>>
>>>> On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
>>>>> While PR53646 claims that c++98 and c++11 should be ABI
>>>>> compatible (modulo bugs), the addition of the _M_size member
>>>>> to std::_List_base::_List_impl makes libraries using
>>>>> std::list in headers incompatible
>>>>
>>>>          This is pretty nasty for LibreOffice (and no doubt others). We
>>>> can, and
>>>> often do depend on rather a number of system C++ libraries and at a very
>>>> minimum, having no simple way to detect which C++ ABI we have to build
>>>> against 'old' vs. 'new' - is profoundly unpleasant.
>>>>
>>>>          Is there no chance of having a bug fix that is a revision of the
>>>> (unintended?) ABI breakage in this compiler series ?
>>> That's the direction I'd prefer to see (reversion until we're ready to make
>>> the wholesale ABI changes).  Not sure what the libstdc++ maintainers are
>>> thinking right now.
>> I'm wondering why the libstdc++ list was taken out of the CC list ;-)
>>
>> I don't know what the others think but rather than just reverting it
>  From a RM point of view please go ahead and revert unintended ABI
> breakage on all affected branches.  Add an entry to the respective
> changes file to warn users about the incompatibility present on branches.
I cannot say to have followed all the details of this discussion 
(neither to fully agree with quite a few statements I read in it ;) but 
since I added the _M_size member in 4_7-branch (to fix 49561 and of 
course in order to provide C++11 conforming complexities for the various 
operations) I'm simply going to revert the change from branch and 
mainline. Consider it done. Then, it would be great if Jon could devise 
something more sophisticated, not throwing away the baby, so to speak ;)

I also want to mention (I don't think somebody did already in the 
thread) that at some point, with Jason too, we discussed the idea of 
adding to each binary a marker about the ABI version which then would be 
used by the linker to warn or error out. This vague idea goes  of course 
well beyond our specific needs for the C++98 conforming std::list vs the 
C++11 conforming version of it.

Thanks,
Paolo.

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jeff Law]

On 07/02/2012 11:53 AM, Paolo Carlini wrote:
>
> I also want to mention (I don't think somebody did already in the
> thread) that at some point, with Jason too, we discussed the idea of
> adding to each binary a marker about the ABI version which then would be
> used by the linker to warn or error out. This vague idea goes  of course
> well beyond our specific needs for the C++98 conforming std::list vs the
> C++11 conforming version of it.
Yup.  I've floated this idea as well.  Some kind of note section with 
abi information in it plus some linker magic to detect and error/warn 
when mixing/matching bits with different abis.

Jeff

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Michael Matz]

Hi,

On Mon, 2 Jul 2012, Jeff Law wrote:

> On 07/02/2012 11:53 AM, Paolo Carlini wrote:
> > 
> > I also want to mention (I don't think somebody did already in the
> > thread) that at some point, with Jason too, we discussed the idea of
> > adding to each binary a marker about the ABI version which then would be
> > used by the linker to warn or error out. This vague idea goes  of course
> > well beyond our specific needs for the C++98 conforming std::list vs the
> > C++11 conforming version of it.
> Yup.  I've floated this idea as well.  Some kind of note section with abi
> information in it plus some linker magic to detect and error/warn when
> mixing/matching bits with different abis.

As we see in the PR it's also the dynamic loader that would have to 
prevent mixing any c++98 and c++11 code in the same process image :-/


Ciao,
Michael.

Re: libstdc++ c++98 & c++11 ABI incompatibility

[Jason Merrill]

On 07/03/2012 08:08 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 2 Jul 2012, Jeff Law wrote:
>
>> On 07/02/2012 11:53 AM, Paolo Carlini wrote:
>>>
>>> I also want to mention (I don't think somebody did already in the
>>> thread) that at some point, with Jason too, we discussed the idea of
>>> adding to each binary a marker about the ABI version which then would be
>>> used by the linker to warn or error out. This vague idea goes  of course
>>> well beyond our specific needs for the C++98 conforming std::list vs the
>>> C++11 conforming version of it.
>> Yup.  I've floated this idea as well.  Some kind of note section with abi
>> information in it plus some linker magic to detect and error/warn when
>> mixing/matching bits with different abis.
>
> As we see in the PR it's also the dynamic loader that would have to
> prevent mixing any c++98 and c++11 code in the same process image :-/

We don't want to prevent mixing different versions; we want them to 
coexist as much as possible, just prevent them from being treated as the 
same.  I posted some ideas for moving forward in a new thread:

http://gcc.gnu.org/ml/gcc/2012-07/msg00031.html

Basically, I'm wondering if we can extend the compiler to use symbol 
versioning to deal with these issues.

Jason