PSARC/2008/549 - Apache Standard C++ Library

[Steve Clamage]

On 09/04/08 12:46, Garrett D'Amore wrote:
> Stefan Teleman wrote:
>>
> 
> I guess at this point, I have the feeling that we need a way to 
> standardize upon a single C++  ABI, combining the results of the C++ 
> compiler implementation *and* the "standard" libraries.  This feels like 
> something that needs to be resolved with a scope that falls well outside 
> the fair bounds of a fast track.
> 
> Right now, it doesn't seem like any of our binary compatibility 
> guarantees apply to any dynamically linked C++ code, and this case (as 
> proposed) proposes to set new precedent here.
> 
> Alternatively, if this library were delivered within a project or 
> consolidation, not for use outside of the project/consolidation (and no 
> additional "public" C++ library dependencies were exposed otuside of the 
> project/consolidation), then I'd be OK with this as a fast track.  That 
> would rescope this effort rather drastically, but then it would also 
> suggest that this particular project should deliver as part of a larger 
> whole such as KDE, rather than as a separate case unto itself.
> 
>    -- Garrett
> 

I have no opinion about whether you should deal with ABI issues in this 
ARC case. But let me put the C++ ABI status into context.

I wrote a rather long paper in 2002 on this topic. The gory details are 
here:
http://developers.sun.com/solaris/articles/CC_abi/CC_abi_content.html

SUMMARY:

The C++ Standard allows many degrees of implementation freedom, leading 
to incompatible ABIs. The C++ Committee chose not to specify an ABI because
- One would have to be specified for every different architecture, and 
new architectures come along every year.
- Different OS's have incompatible ABI requirements, so you need an ABI 
for every combination of architecture and OS.
- Different ABI design choices have different performance 
characteristics. The market should be able to choose among trade-offs.
- From time to time a new solution to an ABI problem is discovered. A 
fixed ABI prevents innovation.

Sun C++ 3.x was based on Cfront, which generated C source code that was 
then compiled by the C compiler.

Sun C++ 4.x in 1993 compiled directly to object code. Going through C 
source code created inefficiencies that need not be suffered in a new 
compiler, so this compiler got a new ABI.

The 1998 C++ standard added features and changed features that could not 
be supported by, or required changes in, the C++ 4.x ABI. C++ 5.x 
therefore got a new ABI. For compatibility, C++ 5.x can also generate 
the C++ 4.x ABI.

The C++ 5.x ABI has known bugs that we cannot fix without breaking 
binary compatibility. To help customers who could not work around the 
ABI bugs, we added an undocumented compiler option to generate a correct 
ABI, but one that was incompatible with the default ABI.

The 2010 C++ Standard will require a new ABI for at least the library. 
Some basic language features arguably require an ABI change. We will 
take advantage of this situation to release C++ 6.x with a new ABI that 
fixes known bugs, and a fully-conforming library (almost certainly 
Apache libstdcxx). We will support the C++ 5.x ABI and continue to 
provide libCstd. Whether we will provide STLport is not yet decided.

CONCLUSION:

1. Sometimes bugs are discovered and you have to choose between 
stability and correctness.

2. Changes in the language definition can require an incompatible ABI.

---
Steve Clamage, stephen.clamage at sun.com