On 09/04/08 12:08, Garrett D'Amore wrote:
> Steve Clamage wrote:
>> Regarding g++, let's take a step back.
>>
>> There is nothing special about the Apache library. It is an
>> implementation of the API (programming interface) described by the C++
>> standard. *We* care about it because the two implementations of the
>> C++ standard library currently supplied with Sun Studio are each
>> missing features that some applications need. ("Why" is a long story.)
>>
>> If you write to the C++ standard API, it should not matter which
>> implementation you use. It will matter only if you have a deficient
>> implementation. (Missing features, non-standard behavior, or poor
>> performance, for example.)
>>
>> G++ comes with its own implementation of the C++ standard library that
>> is quite standard-conforming. You should be able to build the apps
>> with g++ without the Apache library. (If you have tried and found that
>> they don't work, I would be surprised, because nearly all Open Source
>> apps are developed using gcc, then tweaked to work with other compilers.)
>
> Ah, that was not something I was aware of -- I thought GNU C++'s library
> also fell short of the mark. Given that it's not, I'm surprised that
> Apache decided to create their own implementation instead of just
> telling folks to "use Gnu C++". I guess we should be glad they took
> the time to make an alternate implementation available for us!
The source code for the g++ runtime libraries make extensive use of g++
extensions. Few compilers other than g++ can compile the code.
Still other good implementations exist, but they are either proprietary
or must be purchased. For Sun, the cost to distribute the best
commercial library (Dinkumware) would be prohibitive to include in a
product that we don't charge for, and the source code could not be made
public in any event.
>
>>
>> I think that if we created a version of libstdcxx built with g++,
>> there would be no users. Using libstdcxx with g++ has at least the
>> same issues as using libcstdcxx with Sun Studio without direct
>> compiler support -- command lines get rather tricky. And it's not
>> clear that libstdcxx would have significant advantages over the g++
>> library in any case.
>
> Okay, if other folks can corroborate your claims, then I agree we can
> safely dispense with any need for a g++ port.
You (for some definition of "you") should try building with g++. My
guess is that everything will just work.
>
>>
>> G++ has an additional trouble spot: the g++ ABI is not particularly
>> stable. If you build a library with one version of g++, you cannot be
>> sure it will work with another compiler version. If we provided a g++
>> version of libstdcxx, we would have to document it as known to work
>> with only a specific version of g++.
>
> Yeah, good point. I'm surprised more people don't complain about this
> instability.
G++ users expect to recompile everything if they change compilers. ISVs
who use g++ don't distribute dynamic libraries. They also tend to stick
with one centrally-controlled compiler for years at at time. For
example, Google did not move away from gcc 2.95 until June 2006! They
made the new compiler available for unit testing months ahead of time,
switched compilers globally at the same instant, then recompiled their
entire code base.
This is not the kind of world we are used to here at Sun. :-)
>
>>
>> My recommendation is not to consider further a g++ version of libstdcxx.
>
> Concur, provided that no contradictory information to your claims surface.
>
> -- Garrett
>
---
Steve Clamage, stephen.clamage at sun.com
