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
>
> 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. I thought that STLport
is supposed to be standards compliant. 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).
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. (The older
compatibility libraries can stay as is, and might need special compiler
options to make use of them.)
>
>>>> 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.
>
>
> The purpose of this Case is not to engage in a religious debate as to
> which of the two (STLport or stdcxx) libraries are better.
Having more options here is harmful (even toxic). By presenting the
option, you've opened up the debate, whether you intended to or not.
>
> I've already explained the inherent weaknesses of STLport, and the
> advantages of Apache. By sumbitting an ARC Case for Apache, and not
> STLport, the Case already implicilty asserts that Apache is better
> than STLport.
So are you engaging in debate or not? I'm confused.
> This argument seems to be supported by usage in the industry. The
> Apache library is really nothing more than the RogueWave Standard C++
> Library.
I'm not disagreeing with you.
>
> Interesting that full internationalization and localization support,
> which is a *requirement* for integrating software in Solaris, is
> presented here as a weakness or defect. In light of this unusual line
> of argumentation, may i ask: has the requirement for
> internationalization and localization support in Solaris been dropped,
> and the strategic direction changed, to not support these facilities ?
No. (Although C++ has some serious weaknesses with i18n, the last time
I looked. In particular the cstream stuff seemed horribly busted with
respect to i18n. Though the last time I tried to update C++ code for
i18n was when I was working on the E10k service processor stuff over a
decade ago. At that time it was far easier to just scrap the C++ code
and rewrite the applications in C. The resulting applications were a
lot smaller in both line count and run time as a result, but that's a
separate rant.)
Anyway, the problem with i18n is making sure that whatever the language
does works well with the operating system. Having another database of
i18n related information that has to be managed separately from our
existing locale databases will create additional headaches (someone has
to manage the contents of those databases after all), and so should be
reviewed by ARC. You can't just ignore issues like this by declaring
the case a fast-track.
>> 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.
>
> The GNU C++ Compiler is known to break C++ ABI between minor or even
> micro releases.
The GNU C++ compiler doesn't care about compatibility -- that's obvious
from their track record. We can't fix that, but we can and do offer a
better stable alternative. I don't think anyone (at least outside of
the GNU group) seriously suggests that the GNU C++ compiler should be
the "compiler of choice" for C++ code on Solaris.
Btw, the GNU compatibility problems are not unique to g++. Ask someone
someday about the headaches that revolved around updates to GNU libc.
>
> This case does not propose building the library with the GNU compiler,
> and does not address the weaknesses of the GNU compiler. Comparisons
> between the GNU compiler and the Sun Studio compiler are not germane
> to, or in scope for, this case. Many other compilers have many other
> different problems, none of which are being addressed in this Case.
The intent was to point out the problem that this case raises, which is
not unlike the g++ ABI problem. Its a comparison, and IMO, a very valid
one. The GNU libc example above is probably even more relevant,
although at least in that case nobody seriously suggested that the older
libc would be kept around forever and ever -- it was expected that folks
would transition to the new one, and the need for the old one would
eventually go away.
I suspect that we could treat the older libCrun.so (and possibly even
STLport, if that is determined to be the best choice) similar to the
older libucb environment -- something we supply for folks who absolutely
require it, but not something we seriously advocate that anyone who has
a choice use.
But this case (as you've presented it) fails to do that, and fails to
provide any guidance about one library versus another. It just adds yet
another incompatible C++ library.
>
>> - There will be TR2 and eventually the next version of the Standard.
>> Being 'Committed' may make the hurdle to accomodate these revisions
>> very high.
>
> Yes, the Library ABI will break again when the new Standard is
> adopted. This will require a new Library. This is a known fact, right
> now, and this is precisely the reason why the directory layout
> structure for Apache is organized the way it is: /usr/include/stdcxx.
> When the new Standard is implemented in a new library, it will maybe
> go into /usr/include/stdcxx0x, and the library names, and the binding
> SONAME will be different.
>
> This Case does not attempt to address "what might happen in the future".
Submitters of ARC cases should have reasonable plans for future growth
and directions, and try to allow for them. You might guess wrong about
what happens, but if you've made some reasonable effort to allow for it,
then there is less likely to be problem. Putting your head in the sand
isn't a good option, IMO.
>
> This Case is about the integration of a Fully Standard Compliant
> Standard C++ Library. Insofar as the future direction of the Standard
> C++ Library is concerned, in an as-of-yet unapproved ISO Standard,
> this Case cannot address the non existing standard.
If the language changes require ABI breakage, then there isn't a lot
that can be done (other than not to use C++!) But we can at least
discuss whether or not that is likely, and try to design a situation
that will minimize the pain that such breakage will incur, at least in
our system supplied libraries.
>
> The C++ Standard implemented by this library is ISO/IEC:14882:2003.
> That Standard has been approved.
>
>> - 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).
>
> This argument is equally valid for the Standard C Library, or, for
> that matter, for any other compiler/compiled language combo. "You can
> maintain ABI compatibility only as long as the compiler does". True.
> If the Sun C Compiler decides to break the C ABI, the Standard C
> Library will break. The same statement is equally true for Fortran.
Yes, but they generally don't break the ABI.
>
> How is this relevant, or particular, to C++, and the Standard C++
> Library being proposed in this ARC Case ?
>
> The "Committed" Interface Stability classification level, assigned to
> this library, implies, or states, _nothing_ about the *compiler's* C++
> ABI Stability Level, given that the library does not control the
> compiler's ABI stability level. If the compiler breaks the C++ ABI,
> then all the libraries built with said compiler will break, including
> existing "Committed" ones. This hypothetical breakage is beyond this
> Case's scope, or control. This Case is *not* about the Sun C++ ABI.
>
>> 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.
>
> Again, the Sun C++ Compiler's C++ ABI is not being addressed in this
> Case.
>
> Again, there appears to be confusion between the compiler's C++ ABI
> and one library, or another's ABI.
>
> Compiler C++ ABI != Library ABI.
For my purposes: ABI = union(C++ compiler ABI, library ABI)
Breakage of either the compiler or the library interfaces will cause
binaries to break.
>
> This Case assigns "Committed" to the interfaces of the Standard C++
> Library because: [1] the library implements an Industry Standard and
> [2] the interfaces are not expected to change in an imcompatible way,
> given that these interfaces have been defined in a Standard.
>
> For all we care, this Library can stay as is for the remainder of time.
>
>> 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.
>
> Again: STLport is first of all: obsolete, only supports the "C"
> locale, and it has significantly less industry traction than
> Apache/RogueWave.
So then lets have a full plan to transition to Apache instead of this
half-baked proposal.
>
> Also, this case does not propose the integration of a "vastly more
> standards compliant" library, since the definition of "vastly more
> standards compliant" is in the eye of the beholder. This case proposes
> the integration of a Fully Standard Compliant library. This is a very
> significant difference.
Again, lets have a plan to transition then.
I would like to see the compiler folks involved, along with a more
complete plan for how this fits in the big picture, and how we
transition (if that is required) away from STLport.
I'm on the verge of coming out of sabbatical just for this case, if only
so I can derail it. It fails on many significant points to meet the
obviousness test required of a fast track.
-- Garrett
