Stefan Teleman wrote:
>
>
> Garrett D'Amore wrote:
>> 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?
>
> These differences cannot be rectified, due to the backwards API
> compatibility constraints of the existing libCstd.so.1. In other
> words, the existing libCstd.so.1 is frozen in time. It is currently
> not Standard C++ Compliant, and has been so for 10 years. This means:
> any Sun customer developing Standard Compliant C++ software (meaning:
> wanting to use Standard Language features unavailable in libCstd.so.1)
> will either:
>
> 1. Not use Sun Studio.
> 2. Not use Solaris.
Seems like coordination with the compiler folks is in order here. More
below.
>
>> 2) It seems like we (Sun and OpenSolaris both) ought to be putting
>> our weight behind *one* of the implementations.
>
> As explained above, we cannot do that, unless we want to remain
> Standard C++ non-compliant forever.
Not true. It may be true that the existing libCstd.so.1 is not adequate
to the task. But then we ought to either start encouraging folks to use
some thing else (e.g. this project) -- and mark the legacy API/ABI
Obsolete (possibly with an EOF notice as well!), or enhance the existing
library (not sure if that is even possible.)
We aren't stuck in time. I'm not saying we shouldn't ship t Apache
Standard C++ (I'm not prepared to make value judgments of one library
versus another -- I abhor C++ and haven't used it seriously for ~10
years).... I'm saying that we need a *plan* for what we are going to do
going forward -- there should be a single default system C++ library
that is good enough for everyone except folks with particular backwards
compatibility concerns.
>
>> If the Apache version is the best version (I gather that the Studio
>> supplied libraries are somehow deficient, but I don't understand why),
>
> libCstd.so.l must maintain compatibility with Sun Workshop 5. At the
> time Workshop 5 was released, the compiler did not implement all the
> language features mandated by the Standard. The deficiencies were
> primarily in the compiler support for Partial Template
> Specializations, std::iterator_traits, etc.
>
> Introducing support for these mandatory language features in the
> current libCstd.so.1 would break compatibility with the existing
> libCstd.so.1 (for example, because the sizes of some of the existing
> classes and structs in the Standard C++ Library and STL will change).
I see. So, then perhaps we should *strongly* encourage folks to move
away from the legacy library, if that's we want to do. (Part of this
can happen by coordination with the compiler folks to get them to adopt
a new standard library, possibly making the old library available only
with extra options.)
At the end of the day, I'd like to have the situation where the default
compiler flags build code that Just Works, and have that code support
the standards.
>
>> 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.
>
> Indeed it has.
>
>> 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.
>
> There appears to be confusion here between the Sun C++ ABI, and the
> library incompatibility between the existing libCstd.so.1 and the
> Apache Standard C++ Library. The Sun C++ ABI does not change with the
> introduction of the Apache library. Actually, the Apache library links
> against the existing libCrun.so.1, and will conform to the Sun C++
> ABI. It is the Library ABI's that are incompatible.
Actually, ABI can *also* refer to the interface between linked modules
-- i.e. binary compatibility. I.e. there is a more general notion of an
ABI than just what the compiler emits.
>
> C++ developers are well aware of incompatibilities between different
> implementations of the Standard C++ Library. These incompatibilities
> exist regardless of the compiler ABI in use. The GNU Standard C++
> Library is not compatible with the Apache Standard C++ Library,
> either, even in the case where both were compiled with the exact same
> compiler.
>
> This library compatibility conflict currently exists today, in
> Solaris, with the presence of the STLport implementation of the
> Standard C++ Library. However, the Apache implementation of the
> Standard C++ Library is far superior to STLport (if for no other
> reason other than full internationalization support in Apache, which
> is absent in STLport). And even if it wasn't superior, STLport is
> still incompatible with libCstd.so.1 as well.
Pity the poor noob C++ programmer that has to figure out the link
dependencies! Or the poor admin who downloaded some sources from the
'net and can't seem to make them compile properly, because he can't
resolve library incompatibility issues.
Just because the problem exists today does not mean we should make it
worse. I firmly believe that We Can Do Better Than That. Some basic
planning and engineering work is called for here, IMO.
I'm not married to any one of these APIs, and I understand that some
incompatibilities will exist during a transition period. But there
should be a transition period, at the end of which one can reasonably
expect the libraries bundled with the OS (and typically used by most 3rd
party libraries as well) to Just Work, with the default compiler flags.
I hate the g++ versus Sun C++ ABI incompatibility, and I'm not asking
the project team to solve *that* problem. But I am asking that before
we ship another incompatible implementation, we have a *plan* for how to
make the problem *better* instead of *worse*. (Making it temporarily
worse is OK, if in the long run it will be better.)
>
>> 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.
>
> Standards Compliance trumps potential (although not really possible)
> developer confusion.
We can have both, I think. I'm unwilling to believe that we have to
live in this current morass forever and ever.
>
>> 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.
>
> This is not a degree or measure of freedom, this is a matter of
> becoming compliant with an Industry Standard which was adopted 10
> years ago, and which is supported by all our competitors (I am
> deliberately not including GCC in this statement, since GCC does not
> observe the same compatibility constraints to the same degree to which
> the IBM, HP and Microsoft compilers do).
>
> This lack of compliance prevents us from introducing other C++
> components (read: BOOST) which are currently widely used in the
> industry, and by our customers.
I get it. I'm not advocating *against* integrating Apache libstdc++...
I'm asking for a transition plan that gets us to the point where the
compilers Just Work, and we don't have to explain to customers which
library to use or ask customers to provide a byzantine set of options to
override the compilers default headers.
I think some collaboration with the compiler group is probably also
called for here.
>
>> 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.
>
> And that is exactly where the vast majority errors will occur.
>
> The case of "random application misbehavior" simply does not exist
> when linking against conflicting Standard C++ Libraries. The
> application simply crashes on startup, if it manages to link, and if
> the link editor did not already cause fatal errors because of either
> undefined or multiply-defined symbols.
>
>> I consider these compatibility concerns rather grave.
>
> Any C++ software developers worth their title knows that "Thou Shalt
> Not Mix Different Implementations Of The Standard C++ Library." This
> is not a language bug, it is a language feature.
I think you're placing a lot of credit towards C++ developers. Remember
that not everyone that compiles code is a developer! We need a
*canonical* Standard C++ library. If ours isn't good enough, then it
either needs to evolve so it can become good enough, or we need to
transition to a better one (such as Apache's).
This is one area where choice is *not* good, it actually makes things
far worse than they should be. I
I hope someone derails this case. If I weren't on sabbatical I'd be
punching the derail button.
-- Garrett
