Re: [boost] [Boost 1.41: list_of] Boost compliation error, > Sun Studio 11 using standard C++ lib
So, with limited resources (time, labour, and technical expertise on complier), would it be safe to assume that i should pursue other routes (e.g. boost with gcc or with stlport) and not continue with the beast (compling boost with libCstd?). Your professional opinion is much appreciated.
Message: 2 Date: Sun, 03 Jan 2010 04:10:23 +0000 From: Mateusz Loskot <mateusz@loskot.net> To: boost@lists.boost.org Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, Sun Studio 11 using standard C++ lib Message-ID: <4B4018AF.2020705@loskot.net> Content-Type: text/plain; charset=ISO-8859-1
Steven Watanabe wrote:
AMDG
shing fan wrote:
I'm having trouble building Boost headers (e.g. <boost/assign/list_of.hpp> ) with Sun Studio 11 using standard C++ library. I have no problem when i build the headers using the stlport lib. However, due to some restrictions, i have to use the standard c++ lib but not the stlport lib. Does anyone know whether it is possible to complie the following headers using sun studio 11 with ONLY the standard C++ library? I'm okay to use even 1.38 as long as i can compile it with Sun Studio 11 using ONLY the C++ standard library.
The default standard library for Sun is not supported because it is insufficiently standards compliant.
I would quote Roman Shaposhnik's workshop [1] from Sun:
"BOOST with libCstd.so.1 : Can Happen, but is insane"
[1] http://www.osdevcon.org/2008/files/tutorial-roman/
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
_________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://go.microsoft.com/?linkid=9691815
On Sun, Jan 3, 2010 at 13:45, shing fan <shingfan@hotmail.com> wrote:
So, with limited resources (time, labour, and technical expertise on complier), would it be safe to assume that i should pursue other routes (e.g. boost with gcc or with stlport) and not continue with the beast (compling boost with libCstd?). Your professional opinion is much appreciated.
This is what you needed to do for boost 1.33.1 to get it to compile with Studio 12: http://kdesolaris-svn.cvsdude.com/branches/BOOST/1.33.1/Solaris/ see the README.Solaris file. I haven't tried building more recent boosts with libCstd.so.1 since then. You can build most of boost 1.40.0 with Studio 12 [ with the latest patches ] and the Apache Standard C++ Library 4.2.1, which is available in Solaris/Nevada builds, but not in Solaris 10. There are several boost libraries which do not compile with either Studio 12 or Studio 12 Update 1, even with the Apache Standard C++ Library combination above. One library which pops in my mind right now is Boost.Interprocess -- it requires C++0x compiler features [ rvalue refs ], and this feature is not yet available with Sun Studio. You can build recent boosts with GCC 4.3.x on Solaris. Please keep in mind that GCC C++ binaries are ABI incompatible with Sun Studio C++ binaries, and you will not be able to mix and match compilers. HTH, --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com
On 01/03/2010 11:45 AM, shing fan wrote:
So, with limited resources (time, labour, and technical expertise on complier), would it be safe to assume that i should pursue other routes (e.g. boost with gcc or with stlport) and not continue with the beast (compling boost with libCstd?). Your professional opinion is much appreciated.
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. Rob
I do not intend to start a flamewar, but the post below contains numerous factually wrong, incomplete, misleading and uninformed statements. 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 stlport4 library. Thank you for your time. --Stefan ------ On Sun, Jan 3, 2010 at 15:12, Rob Riggs <rob@pangalactic.org> 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.
Rob
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Stefan Teleman KDE e.V. stefan.teleman@gmail.com
Please do not top post. On 01/03/2010 01:44 PM, Stefan Teleman wrote:
On Sun, Jan 3, 2010 at 15:12, Rob Riggs<rob@pangalactic.org> 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.
[Lots of text elided for brevity.]
the post ... contains numerous factually wrong, incomplete, misleading and uninformed statements.
Stefan, I believe my post is quite well informed. And your reply seems to be intended to confuse the issue by discussing the state of affairs of OpenSolaris. My statements do not apply to Nevada. My statements apply to Solaris 10. This is the platform most Solaris developers target in production environments. You are using the same tactics that Sun sales staff use to pitch their operating system capabilities -- by pointing to features that exist only in a development version of the operating system and speak as if that were what people use on a daily basis. It is disingenuous at best. I notice you did not post this from your sun.com account. Do you still speak for Sun? Stefan, I have followed your work on PSARC/2008/549 and am very encouraged by the work you are doing. But it is also from the public discussions that leave many of us questioning the status of this work. The fact is this has not made it into Solaris proper yet and there has been no public indication that I can find as to when it will make it into Solaris. 12 years after c++98 and 7 years after c++03 was ratified and the only compiler shipped by Sun that supports these standards is GCC. What is going to happen with c++1x?
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.
There is nothing erroneous in my post. The purpose of my post was to aid fellow Solaris developers by providing some of my hard-won experience on this platform. I do not see anything that confuses the topic beyond what is admittedly a confusing state of affairs for C++ on Solaris. You are the one intentionally confusing the issue here.
- 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.
Sun's history with libCstd and with STLport implies that they would rather live with a non-standard C++ environment than break the ABI again. That this does not address c++1x is clealy pointed our in the PSARC opinion paper. I am unfamiliar with Sun's internal workings. But my understanding is that libstdcxx is going into the next Solaris version to provide c++03 compliance and that another version will need to be approved to support c++1x. That sucks for us C++ developers. It will be like libCstd and stlport4 all over again.
- 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.
GCCFSS is relevant to this discussion as it is the only full-featured and standards-compliant C++ compiler that supports locales readily available on Solaris 10.
Thank you for your time.
--Stefan
Our decision to switch from Sun Studio to GCC was an economic one. The compiler that provides the most economic gain for us wins. In today's market, for software that impact our business, the value to us of open source software that compiles with GCC (and that does not compile with Sun Studio) dwarfs the value of commercially available software packages that require Sun Studio. That is true today and the economics are not likely to ever swing back in favor of Sun Studio. Regards, Rob
On Sun, Jan 3, 2010 at 20:12, Rob Riggs <rob@pangalactic.org> wrote:
Stefan, I believe my post is quite well informed.
It is not. I have already said so once. I am not going to engage in some silly tit-for-tat with you. I will only address one paragraph from your latest post, below. The rest of it isn't worth my time.
I notice you did not post this from your sun.com account. Do you still speak for Sun?
I never speak for Sun. I am not a Sun Microsystems spokesperson. if you are seeking Sun's official position on any topic of interest, please contact Sun's Public Relations office. I presume you are impertinently inquiring about my employment status with Sun. The answer is yes, I am still employed at Sun. It is not clear to me how my employment status is any of your business, or how it is relevant to Boost. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com
participants (3)
-
Rob Riggs -
shing fan -
Stefan Teleman