PSARC/2008/549 - Apache Standard C++ Library

[Garrett D'Amore]

Stefan Teleman wrote:
>
>
> Garrett D'Amore wrote:
>> John Plocher wrote:
>>> Garrett D'Amore wrote:
>>>> I don't see Gnu C++ mentioned explicitly,
>>> It mentions C++ ABI - something that Studio has and g++ does not.
>>> From an ARC perspective, that is all that really matters.
>>>
>>> Note the dates on the document - 1993-ish.  One reason it is not
>>> on OS.o is that it needs updating, which is not a trivial job.
>>>
>>>> Right now, it doesn't seem like any of our binary compatibility 
>>>> guarantees apply to any dynamically linked C++ code,
>>> Rather, dynamically linked C++ libraries that are NOT ABI Compliant.
>>> Studio C++ does generate ABI Compliant code, g++ does not.
>>>
>>>> and this case (as proposed) proposes to set new precedent here.
>>> What would that be?
>>
>> You've supplied (in previous e-mail) other documents providing more 
>> detail than the reference Stefan supplied.
>>
>> Anyway, this case essentially proposes to create a new ABI, *not* 
>> based on version 5 libC, but based on a different library (I'm not 
>> talking about the Compiler's ABI, but the "overall" ABI composed of 
>> the library and the compiler combined.) 
> ¹While this might not be the large precedent
>> I first thought it was, I still don't think it appropriate to do so 
>> without a full case.  It violates the normal obviousness and 
>> non-controversialness rules for fast tracks.
>>
>> A reduced-scope delivery of the library, with project or 
>> consolidation private bindings would be satisfactory
>>
>> So, let me put this into direct, actionable terms:
>>
>> 1) If the project is willing to reduce the scope to project or 
>> consolidation private, then I withdraw my objections.
>
> Project/Consolidation Private to whom ? Both KDE and JDS intend to use 
> it.

Then perhaps each of them winds up with their own project private 
copies.  Or perhaps one of them gets a contract from the other.  I don't 
know what the best solution involving non-public binding is.  Clearly, a 
Public Committed API is better.  I just don't think a Public Committed 
API and (more importantly) ABI can be arrived at in the scope of a fast 
track.
>
> That would defeat the purpose of the integration in the first place.
>
> You are essentially saying:
>
> 1. We are introducing a Standard compliant library which was not 
> present before.
> 2. You [ Solaris Developer | Sun Customer ] have been waiting for this 
> library for 10 years.
> 3. This library tracks the 2003 C++ Standard.
> 4. You [ Solaris Developer | Sun Customer ] cannot use this library.

I'm saying that this is true *unless* you're willing to step up to the 
plate to provide the guarantees that would be required, and that I think 
it would require a full case review in order to fully assess that.

I'm *not* saying we can't or shouldn't ship this.  I'm saying that we 
shouldn't do the job improperly.

PLEASE, don't make the mistake of believing that that derail == deny.   
All derail means is that the project falls outside of the scope of 
"obviousness" that makes it appropriate for a fast track.  The large 
amount of discussion we've already had around this project (and 
continued levels of "discovery" surrounding the case) strongly represent 
to me that this case is *not* obvious, and should not be a fast track.

*However*, if you're only worried about one or two consumers, and are 
willing to have a greatly reduced commitment, then I'm willing to stand 
aside and let it go as a fast track.

But lets not pretend that you can create a new C++ ABI (and thats what 
this case as proposed would do!) without properly addressing the 
compatibility considerations and without a regular and complete review.

    -- Garrett
>
>> 2) Else, *I* will derail the project.  (Note that derail != deny, but 
>> it affords us time to ensure that the project is properly reviewed, 
>> and the opportunity to give appropriate advice.)
>
> --Stefan
>