Stefan Teleman wrote:
>
>
> Garrett D'Amore wrote:
>> John Plocher wrote:
>>> Nicolas Williams wrote:
>>>> It would be
>>>> nice if we could avoid revisiting this every time a project comes
>>>> along
>>>> to integrate some C++ library.
>>>
>>> We already have a stake in this sandbox:
>>>
>>> Don't use g++ to build/deliver C++ libraries on *Solaris,
>>> period. Use Studio's C++ instead.
>>
>> Oh, cool! Do you happen to know offhand what the case number for
>> that opinion would be?
>>
>
> PSARC/2002/348 (International Components for Unicode).
>
Thank you.
I don't see Gnu C++ mentioned explicitly, but it seems like some
specific comments were made about compiler flags, etc. that necessarily
preclude Gnu C++.
Please review the last paragraph in section 4.1.8. I don't know if the
policy has been superseded, but the case clearly recognizes the binary
compatibility problems, and tried to set a policy against Evolving or
Stable. (Which today would mean Committed.) I take that precedent to
mean that it would be inappropriate for any binary compatibility level
to be granted beyond Uncommitted.
And Consolidation or Project Private seems even better (the case
recommends this), with individual contracts for specific use outside of
the consolidation or project.
If this case wishes to propose a new C++ Standard library, with a higher
level of binary stability, then I think it would be appropriate to
escalate this to a full case. The full case would describe how the
binary compatibility guarantees would be used, and might then create
itself a precedent for how middleware C++ could solve the binary
compatibility problem. It would necessarily need to involve input from
both compiler teams and the project team (and possibly potential
consumers such as KDE as well.)
I guess at this point, I have the feeling that we need a way to
standardize upon a single C++ ABI, combining the results of the C++
compiler implementation *and* the "standard" libraries. This feels like
something that needs to be resolved with a scope that falls well outside
the fair bounds of a fast track.
Right now, it doesn't seem like any of our binary compatibility
guarantees apply to any dynamically linked C++ code, and this case (as
proposed) proposes to set new precedent here.
Alternatively, if this library were delivered within a project or
consolidation, not for use outside of the project/consolidation (and no
additional "public" C++ library dependencies were exposed otuside of the
project/consolidation), then I'd be OK with this as a fast track. That
would rescope this effort rather drastically, but then it would also
suggest that this particular project should deliver as part of a larger
whole such as KDE, rather than as a separate case unto itself.
-- Garrett
