Re: ABI Issues: C++ PATCH: PR 12053

[Mike Stump <mrs at apple dot com>]

On Wednesday, September 3, 2003, at 04:44 PM, Jason Merrill wrote:
> Given that the library ABI changed with 3.3, it seems to me that 
> perhaps
> binary compatibility within the 3.3 series is more important than
> compatibility between 3.2 and 3.3.

Preface: I'll assume for the sake of the below that the abi bug matters 
(the incompatibility will be detected by customers), this might not be 
true.

At Apple, we are using the abi from 3.3 in our about to be shipped 
(previously shipped preview) product.  Those bits are now frozen for 
better or worse.  It it defined to be abi incompatible with anything 
we've shipped before, and I suspect it will be incompatible with the 
3.4 things to ship in the future because of libstdc++.  We will have a 
follow update that takes us to 3.3.x in the future, but, it is hoped 
and expected that this will be abi compatible with 3.3.  It would seem 
that we (Apple) get the most from 3.3.x being compatible with 3.3, this 
was the natural abi compatibility guarantee from yesteryear.

Now, with that, it sure would be nice if we could get abi compatibility 
without having to think about it.  The problem is, for a competing 
vendor, that is other wise just like us, that shipped 3.2, and no 3.3 
nor 3.3.1, they want the exact opposite of what we want, for the same 
reasons.

It would be nice if we had an engineered solution to this problem that 
just worked by design.

How about revving the abi number every single release, then we could 
name any release we wanted to be compatible with?  Now, the question 
is, how do we then still have the current semantics of the abi number.  
What if we had a major number and a minor number:

3.2:		2.0
3.3:		2.1
3.3.1:	2.2
3.3.2:	2.3
3.4:		3.0

Then, the change in question can:

	if (abi == 2.1 || abi == 2.2)
		3.3 style code
	else
		3.2 style code

We can then have target (os) specific fragments that can override abi:

#define ABI_DEFAULT 2.1

and they can default to

#define ABI_DEFAULT 2.0

This allows for after-the-fact abi incompatibilities and a way to 
request one   over the other.

Without being able to do this, we engineer the game to be unwinnable if 
we ever have a abi bug.  The probability of that is 1.

It would then be nice to have the abi number in the object file 
somewhere and endow the linker with enough data ({2.0, 2.3}, {2.1, 
2.2}) so that it could check for abi compatibility, and warn about 
potential known incompatibilities.

:-(  abi issues are hard; we've not gotten past the tip of the iceberg, 
and what a nice pointy tip it is!