Hi, What I'm going to say really just reiterates the need to coordinate with the compiler group (with which I am not particularly affiliated). But I think I have some more arguments.
Stefan Teleman schrieb: > > 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. That has been done very consciously. And you can't get away from this for any use case that needs compatibility to the long-standing, stable C++ ABI (e.g. because they need to use libraries that are built against libCstd.so). > 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. > If they don't need ABI compatibility on Solaris, there are existing alternative, in particular use of the STLport shipped with SunStudio. >> 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. > Other have already made a strong case that this should be coordinated with the compiler folks. At least there should be agreement whether STLport or stdcxx is the best way forwards. Stepping away from the existing stable C++ ABI towards a new potentially stable ABI would also be a chance to fix any issues (in particular standards conformance issues) that are in the compiler or libCrun and also could not be fixed. This underscores the need for coordinated planning even more. >> 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). > >> 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. > BTW, I see that you suggest giving this library a Committed stability classification. This may lead you into the same corner where libCstd currently is caught: - Experience (e.g. the multitude of 'final stable ABI' releases of g++ and its library) shows that it is very difficult to determine that something is perfect enough that future bug fixes won't require more ABI changes. - There will be TR2 and eventually the next version of the Standard. Being 'Committed' may make the hurdle to accomodate these revisions very high. - You can maintain ABI compatibility only as long as the compiler does. If you commit to an ABI now, you may be stuck with being tied to a -compat switch and can't benefit from compiler improvements, if the compiler group eventually makes the step to a 'major release' (i.e. a new compiler ABI). >> 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. > > 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. > Yes, but this is a PITA. Having a reasonably stable C++ ABI is a precondition for being able to ship binary applications that support plugins or binary plugins for existing applications. This is already pretty messy in cases like Mozilla or OpenOffice.org, which both support extensions through a component model with a native C++ binding. So by all means let's try to make a new, hopefully longer-lasting, stable C++ ABI. But that only works if the compiler and library take that step together. > 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. > But then why is having three incompatible libraries better than two? STLport already supports the most important points of what you are setting out to do: - It is vastly more standards compliant than libCstd (at the cost of being incompatible). - It supports use of most of Boost. If stdcxx is superior to STLport, then that is a transition that the compiler group should make. And the full internationalization might even be a liability. I would expect some nasty surprises, if the locale support in the C++ library is out of sync with the support in the system itself. How do C++ applications behave, if the library doesn't support the current system locale? What happens when data for a locale is inconsistent between system and C++ library, so that C++ applications behave differently from all the others? Wouldn't it be better to add missing locale data to the system than to provide it in a C++-only ghetto? AFAIK there are a few cases already where we have multiple, possibly inconsistent databases for essentially the same data in the system. But any such case should be judged very carefully. >> 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. > The compiler group has operated under the opposite premises - presumably for good reasons. And that confusion is not as impossible as you make it be. And how does availability of STLport not already fulfill the need for a Standards Compliant C++ library? If all you can put forward is QoI, then your argument gets much weaker. >> 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. > It is not only with different compilers (where in C++-land all bets are off). We even now have libCstd (for ABI stability) and STLport (for Standards Compliance). > 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. > Doesn't STLport already address this? >> 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. > The problem situation occurs when components using different C++ standard libraries are dynamically loaded into the same process. If the C++ implementation lives behind a C interface or is loaded in plugin style (dlopen/dlsym), the linker cannot warn you in time. AFAIK there used to be a component (from some layered product), that used a C++ implementation for a name service switch module (at a tiem when these modules were not strictly confined to ncsd). This produced bad runtime crashes when C++/STLport applications called functions like gethostbyname(3NSL). >> 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. > C++ may not always be at the surface. And having to deal with several different libraries with different quirks when creating (e.g.) plugins for different applications is onerous. Adding MORE diversity is the problem, not the solution, here. - J?rg
