This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: GCC compatibility of shared libraries with STL objects in their interface
- From: Robert Fanner <robert dot fanner at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 30 Nov 2015 14:31:40 +0200
- Subject: Re: GCC compatibility of shared libraries with STL objects in their interface
- Authentication-results: sourceware.org; auth=none
- References: <CAHiLU9sktv761ETt2BirL_9iuDVyX+36QXowtWKu0E1B0eMEYQ at mail dot gmail dot com> <CAH6eHdRY2n4QXqMp4jDr2gCxiVECi4Cpsk=Dx78+wRnLu-3N0w at mail dot gmail dot com> <CAHiLU9swZryk8kH+-0zRAi+O=pB4bk-bc8ZbDB_Ak2f+Pioakg at mail dot gmail dot com> <CAH6eHdRKDqKD_VKet4R8dDoOM9-XeZ-AWK0sJ=wE7Fyu7eA_Kg at mail dot gmail dot com>
On Mon, Nov 30, 2015 at 1:13 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 30 November 2015 at 07:23, Robert Fanner wrote:
>>
>> Is there more documentation somewhere with respect to how you've gone
>> about achieving the high degree of ABI stability (e.g. making sure
>> things are inlined/not inlined, data members don't change, memory
>> layout stays the same, inheritance doesn't change, etc)? I'd really
>> like to learn more.
>
> Inlining doesn't matter.
>
> We just don't change things that affect the ABI, even when that means
> we're stuck with a bug that can't be fixed without an ABI change.
> Don't change object layout. Don't change virtual table layout.
>
> Occasional mistakes have happened, but we've reverted the changes.
Thanks!
I was starting to stray from ABI compatibility into the realm of
runtime behavioural compatibility of code. If inlining isn't really an
issue for STL/libstdc++, then I guess it boils down to making sure
inlined code doesn't change private member data state in unexpected
ways across versions.
Rob