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
>
