Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, > Sun Studio 11 using standard C++ lib
From: Stefan Teleman (stefan.teleman_at_[hidden])
Date: 2010-01-03 15:44:47
I do not intend to start a flamewar, but the post below contains
numerous factually wrong, incomplete, misleading and uninformed
It is of great disservice to provide erroneous information, and that
in response to a mailing list request for accurate information about a
specific topic. Not only it confuses the original question, but it
also diminishes the value of the mailing list.
I also realise that this is a Boost mailing list, and it is not a Sun
compiler complaints list.
I will correct the following false assertions:
- Apache Standard C++ Library 4.2.1 [ libstdcxx ] is already included
and available in Solaris/Nevada. Sun Studio 12 provides support for
the Apache Library.
How do I know that libstdcxx is available in Solaris/Nevada ? Because
I put it there.
It is, therefore, not true, that Sun has not given any indication
about the availability of the Apache Library: it is already available.
- Sun does not have to wait until C++0x is ratified in order to
provide libstdcxx, simply because libstdcxx does not yet support
C++0x. There may exist, in the future, an implementation of the
Apache Standard C++ Library, providing C++0x. It does not yet exist.
- It is already known that the C++ ABI will break for C++0x.
- GCCFSS has nothing to do with C++, or, for that matter, with C, or
with std::locale. GCCFSS is simply a compiler backend optimizer for
the SPARC ISA exclusively.
- The stlport4 library available on Solaris has nothing to do with
GCC. It is only provided for, and supported with, Sun Studio. GCC
provides its own implementation of the Standard C++ Library, namely
libstdc++. The implementation of the GNU Standard C++ Library has
nothing to do with either GCCFSS, or with the Solaris-provided
Thank you for your time.
On Sun, Jan 3, 2010 at 15:12, Rob Riggs <rob_at_[hidden]> wrote:
> C++ on Solaris is a bit of a lost cause at the moment. Â The near-term route
> that we have decided to take is to abandon Sun Studio altogether and focus
> on porting to GCC on Solaris using the GCC package from Blastwave. Â I
> encourage others to consider doing the same.
> The issue that you will run into with both Sun Studio & stlport and with GCC
> is that neither has working locale support on Solaris. Â This is not an
> immediate issue for us so it was a reasonable compromise. Â My understanding
> is that locale support should be working in the near future with "regular"
> GCC on Solaris using the --enable-clocale=ieee_1003.1-2001 option.
> Longer term, we do not think Sun Studio is a viable platform for C++
> development. Â In the near future Sun will have to support Sun Studio with 3
> C++ standard libraries as they have stated publicly that they will be adding
> Apache's libstdcxx (but not when). Â This is an untenable position for
> third-party library developers (whether open or proprietary). Â None of the
> three libraries are binary compatible, so every third-party library one uses
> must be compiled with the same library. Â Additionally, Sun will either have
> to wait to include the Apache libstdcxx until c++1x is ratified and their
> compiler & library supports all its features or it will have to support a
> 4th C++ standard library. Â However, given Sun's history with C++ support,
> the option they are most likely to choose is to have a broken C++
> implementation that doesn't support all of c++1x for the next decade.
> GCCfss from Sun is another alternative, but it appears to be at a crossroads
> with GCC's recent license change. Â Sun can no longer modify GCC to produce
> IL code for their compiler back-end without also releasing those tools under
> the GPL. Â Last I checked, this did have working locale support. Â This is
> really the only working C++ implementation on Solaris at this point. Â But
> its lifespan appears to be rather limited.
> Unsubscribe & other changes:
-- Stefan Teleman KDE e.V. stefan.teleman_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk