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

[Garrett D'Amore]

Nicolas Williams wrote:
> On Thu, Sep 04, 2008 at 10:40:57AM -0700, Gary Winiger wrote:
>   
>>> The short version of my position is that the Apache headers and runtime
>>> libraries should not be part of an ON consolidation, but should be 
>>> provided by the Sun Studio compiler team. The headers should be part of 
>>> the compiler, not installed in /usr/include, and the runtime libraries 
>>> should be delivered into Solaris by the Sun Studio team just as other 
>>> C++ runtime libraries are currently delivered.
>>>       
>> 	My understanding is that such things as KDE depend on this library.
>> 	If correct, is the proposal that Sun Studio needs to be
>> 	purchased/installed in order to run KDE?
>>     
>
> The C++ runtime and misc. libraries, like the C runtime and misc.
> libraries, need to be part of the installed system, not part of the
> compiler suite, at least if the runtime takes the form of shared ELF
> objects (as opposed to being statically linked).
>
> The fact that there exist ABI incompatibilities between different
> compilers and even different versions of the same compiler, and the need
> (I assume!) to ship BOTH Sun Studio AND g++ means that we have to find a
> way to deal with multiple C++ runtimes and libraries.  I could be wrong
> about this assumption.  Perhaps we can ship just one of these C++
> compilers, but I doubt it.
>
> It'd be nice to have similar functionality in Sun Studio and g++, but
> given the C++ ABI issues that can't be the most important issue from the
> ARC's point of view, right?  It's got to be to find a way for libraries
> built with both compilers to be available on the installed system, and
> to find a way to keep from confusing developers.
>
> That is, IMO, we should bite the bullet and deal with the multiplicity
> of C++ ABIs.  We should, of course, try to keep those to an absolute
> minimum (that would 2, until g++ breaks its ABI next anyways).
>   

And in fact, I've suggested that we do just this -- deliver the 
libstdc++ as a separate consolidation (or perhaps with other 
Studio-supplied consolidations -- libm, libC).  The consolidation could 
have binaries for both gcc and Studio supplied.

Somehow, I do think we need to have separate library search paths for 
g++ versus Studio.  Maybe we already do -- I don't use C++ so its not a 
problem I normally need to worry about.

I confess I'd rather have the library developed and supplied by the 
studio folks.  The reasons for this are:

1) the studio folks can then add supporting switches (and runtime 
detection) for the library to the compilers
2) there is far less likely to be binary interface breakage if only one 
entity is delivering binaries from a single source repo
3) the studio folks can also address include and library search path 
problems properly in their compilers
4) makes it easier to deal with making this available for S10 updates as 
well (only a single common source repo, no need for separate source trees)

All that said, I'm willing to yield on these issues *if* the project 
team and the Studio team can come to an agreement which will provide a 
promise of *binary* and *source* compatibility both, for applications 
going forward.  (Put another way, if my compatibility concerns, which 
are the main issues I have at stake here, can be suitably resolved by 
the parties concerned -- both the project team and the compiler folks, 
then I'm happy.)

    -- Garrett