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
