Garrett D'Amore wrote: > Stefan Teleman wrote: >> >> >> Joerg Barfurth wrote: >>> 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. >> >>> If they don't need ABI compatibility on Solaris, there are existing >>> alternative, in particular use of the STLport shipped with SunStudio. >> >> So, this is the argument for being out of sync and non-compliant with >> a 10 years old Industry Standard ? "If you don't like that we're not >> Standard Compliant, go elsewhere" ? > > Compatibility sometimes is more critical than standards compliance. One > does not universally trump the other. Breaking a zillion customers' > products just because
For the record: *NOTHING* will break. >> Sad to say, many customers have already done that -- they went >> elsewhere. I didn't realize that chasing customers and developers away >> was a strategic direction at Sun. But maybe i'm misinformed. > > I think you're being intentionally dense here. Thank you. I was aiming for that. > I thought that STLport is supposed to be standards compliant. No, it is not. > If it isn't, then we need to > figure out a solution that either gets it to be standards compliant, or > moves on a transition path towards something else that is (perhaps > Apache's version). Why ? What does STLport have to do with Apache ? The version of STLport4 included with the compiler is no longer maintained, or developed. It's *dead*. The new version of STLport5, is not ABI compatible with STLport4. So, we're back to Square One. > No one is saying this case can't ship. What we (me!) are saying is that > it fails the obviousness test, and there should be some plan for a > solution that consolidates us to a single library for most folks to use, > and that library should be what is used by default. Why ? Where does the requirement for "consolidating into a single library" come from ? The Sun Compiler Team has intentionally put a lot of effort in separating the C++ run-time from the Standard C++ Library. There are two libraries involved in C++ with Sun Studio: libCrun.so.1, and libCstd.so.1. I believe that this separation was intentional, and it was done precisely for the purpose of enabling multiple instances of the Standard C++ Library to coexist, and work, within the same Sun C++ run-time. Do we consolidate into a single library today ? No, we don't. Have we done this in the past ? No, we haven't. Can we honestly assert that we can do this in the future ? No, we can't, because the next iteration of the Standard will break compatibility with the existing one, and that will require a new Library, and this fact is already known today. How do you propose in practical terms to achieve this ? Your are proposing the following: let's change the default compiler behavior, so that it changes the default Standard C++ Library being used, from libCstd.so.1, to Apache. The Apache Library is known to be API and ABI incompatible with libCstd.so.1, so, by changing the default compiler behavior, we have instantly broken all your software. How is this proposal consistent with your earlier assertion that "maintaining compatibility" trumps Standards Compliance ? Or, how is this same proposal consistent with the Principle Of Least Astonishment ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
