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. 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. > 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 -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
