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.
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.)
Is that sufficiently clear enough?
-- Garrett
