So the questions/concerns I have about this are:
1) Is there any long term plan for rectifying the differences between
Studio-supplied Standard C++ libraries and this version?
2) It seems like we (Sun and OpenSolaris both) ought to be putting our
weight behind *one* of the implementations. If the Apache version is
the best version (I gather that the Studio supplied libraries are
somehow deficient, but I don't understand why), then perhaps its time we
take a look at a general move to mark the Sun stuff Obsolete, and direct
users towards the newer version.
3) Given the rotten ABI incompatibilities that exist already in C++, one
could argue that precedent has been set. However, I feel that making
this problem worse by adding yet another system-supplied
and-incompatible C++ library is asking for severe trouble. Without some
long term plan to consolidate on (and recommend) a single ABI,
developers are left confused as to which they should be using.
4) If you have an application that needs to bring in libraries from
multiple sources, each of which were built against different C++
standard libraries, you wind up with a situation where the binary can't
work. And, its not clear to me that the poor developer stuck here
trying to use one set of libraries linked against Apache's code, and
another against Studio's, has a way to know that a problem is lurking,
much less a way to avoid or solve it.
5) Yes, I know that this problem already exists with Gnu C++ versus
Studio compiler ABI incompatibilities. However, I'm strongly opposed
seeing this problem increased by another degree of freedom if we can
avoid it.
6) The failure mode if mislinked programs (random application
misbehavior) makes me very unhappy. I'd far rather have a failure occur
at compile or at least at link time.
I consider these compatibility concerns rather grave. Grave enough that
I'm *very* uncomfortable that this meets the "obviousness" (or
"uncontroversial") test required for a fast track. I think it should be
derailed, so that a broader plan around C++ API/ABIs can be arrived at.
HOWEVER, as I'm still on sabbatical, I don't think its fair for me to
derail it. But I *really* hope that someone else on the committee will
do so.
(Project team, note that I'm specifically *not* trying to prevent
integration of Apache libstdc++ -- rather I want to see a plan evolve
where we can figure out how to arrive at a reasonable predictable and
modern C++ library that doesn't leave developers in a complete
bewilderment about how to build their applications. It may be that the
quasi-major binding status of OpenSolaris gives us an opportunity here
to consolidate on the Apache libstdc++, although I'm not sure whether
that horse might already have left the barn with the OpenSolaris 2008.05
release.)
-- Garrett
John Fischer wrote:
> All,
>
> I am sponsoring this case for Stefan Teleman from the SFW
> group. The case directory contains this proposal, the ANSI
> C++ Standard, 2003 Revision and delivered files appendices.
> I have set the timeout for Monday, September 1st, 2008.
>
> This project proposes to deliver the Apache Standard C++
> library (libstdcxx.so.4) in a Micro/Patch release of
> Solaris. The inclusion of the Apache Standard C++ Library
> in Solaris will enable the adoption, of important developments
> in the evolution of the C++ Language Standard. Most notably,
> it will enable the building and inclusion of the Boost Framework.
> Please note: the Apache/RogueWave Standard C++ Library is not
> binary compatible with the Sun Standard C++ Library
> [ libCstd.so.1 ], or with the STLport Standard C++ Library.
> See the proposal for further details.
>
> Thanks,
>
> John
>
>
