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

[Steve Clamage]

I've been going over with my team the various implications of supporting 
a Solaris version of Apache libcstdcxx, whether it is delivered by a 
Solaris consolidation or by the compiler group.

Let's suppose we go the route suggested by Stefan, where he delivers the 
headers into /usr/include/... and the runtime libraries into /usr/lib.

The feature would not be available on Solaris 9 or earlier. We have 
precedent for such a limitation: full C99 conformance is similarly not 
available. But I don't think restricting the availability to 
SNV/OpenSolaris is acceptable. Currently, full Sun support (e.g. for 
enterprise customers) is available only for Solaris 10. A plan to 
provide support for OpenSolaris is being discussed, but nobody yet knows 
what form that will take.

Will you undertake to deliver Apache libstdcxx into a Solaris 10 patch 
and update?

It might be possible to deliver a single version of the runtime library 
(per platform) compiled with -mt to be used by both MT and non-MT 
programs, but it would have performance implications for single-threaded 
programs. We think a better solution would be to have two libraries, to 
ensure no conflict between MT and non-MT code, and to eliminate 
gratuitous performance loss in single-threaded code. (In MT code, the 
library must lock critical regions of an object during manipulation by 
library functions.)

Will you undertake to deliver both single- and multi-threaded library 
versions?

As discussed earlier, for SPARC, only v8plus (sparcvis) or better will 
be supported, so we eliminate the need to provide different versions for v8.

The compiler team would like to consult with you on the best way 
(compiler options, etc) to build the libraries, and on the library 
configuration parameters.

Subject to agreement on these points, I have no objections to a Solaris 
consolidation taking responsibility for delivery and maintenance of 
libcstdcxx as a Solaris component.

The compiler group will add an option to CC, presumably
     -library=stdcxx
that will take care of disabling use of the default libCstd, and adding 
-I, -L, and -l options to pick up the appropriate version of libstdcxx.

We have already discussed maintaining binary compatibility, which will 
be done via the usual mechanism of external and internal library versioning.

There are probably few minor technical details to be ironed out.

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