AMDG On 12/7/2010 8:12 AM, Dave Abrahams wrote:

On Tue, Dec 7, 2010 at 11:07 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

Is there any specific reason why Boost isn't tested against Sun CC without STLPort -- aside from the obvious reason that there's nobody running the regression tests on that platform? Is it something inherently wrong in Sun's standard library implementation that's preventing Boost from working properly on the Sun compiler? It used to be wicked noncompliant, to the point where it was a waste of time to even try. I'm not sure what the status today, though.

The thing is, the library would be reasonably compliant if it weren't for the compiler workarounds. These aren't needed anymore, but the library configuration still activates them. I'm guessing that the reason is to preserve ABI compatibility. In Christ, Steven Watanabe

AMDG On 12/7/2010 8:19 AM, Beman Dawes wrote:

On Tue, Dec 7, 2010 at 11:07 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

Hi Everyone,

Is there any specific reason why Boost isn't tested against Sun CC without STLPort -- aside from the obvious reason that there's nobody running the regression tests on that platform? Is it something inherently wrong in Sun's standard library implementation that's preventing Boost from working properly on the Sun compiler? Earlier in the year, I download OpenSolaris and the Sun compiler and got them running using VirtualBox on a Windows 7 host so I could check out a Boost Filesystem bug report. No problems that I can remember. I used whatever standard library Sun shipped with their compiler.

I'm away from that machine at the moment, but can look at their standard library implementation tomorrow morning if that would help.

You probably used STLPort. I think Jamroot forces the use of STLPort. In Christ, Steven Watanabe

On Tue, Dec 7, 2010 at 11:28, Dean Michael Berris

Interesting. It would be great if someone could run regression tests on the "latest" version of Sun's compiler and stdlib someday soon.

...

I'm away from that machine at the moment, but can look at their standard library implementation tomorrow morning if that would help.

That would definitely help. Thanks Beman!

http://docs.sun.com/app/docs/doc/821-1383/bkaty?l=en&a=view Support for the Apache C++ Standard Library 4.2.1 was introduced with Sun Studio 12.1 and higher. It can be enabled by passing -library=stdcxx4 to the compiler. This flag is a no-op if the library is not installed on the system (it must be installed separately). The library is currently available on Solaris 11 Express only -- released in November this year. It may [ very likely will ] also be available in a future Solaris 10 Update release. If anyone is interested in testing Boost with Apache stdcxx on Solaris 10, and need Solaris 10 [ any version ] packages for the stdcxx library, please contact me privately. It is also possible to use Apache stdcxx with Sun Studio 12. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com

Hi. My answers inline. On Tue, Dec 7, 2010 at 20:41, Dean Michael Berris <mikhailberis@gmail.com> wrote:

Okay, as I understand it the STL that Sun uses (libCstd) is a RogueWave derived STL -- which subsequently is the same library which became Apache stdcxx. Is stdcxx the new default or is libCstd still the default with later versions of the compiler/OS?

Yes, libCstd is in fact a very old version of RogueWave. But it's so old, it is not ABI compatible with the latest Apache stdcxx V4 (I think libCstd is based on RogueWave Version 2). And it was initially severely crippled due to the C++ compiler limitations in Sun Workshop 5 (yes, it's that old!).The default STL library is still libCstd for the Studio compilers, even for the latest versions (12, 12.1 and 12.2).

Thanks, so I just need to check whether I can get access to Solaris 11. I'd guess if I would need to support older compilers then Boost would be a no-go.

Solaris 11 Express is a free[1] download here: http://www.oracle.com/us/products/servers-storage/solaris/solaris-11-express... If you don't really want to deal with downloading and installing Solaris 11 Express, and already have a Solaris 10 release installed on a box, please let me know, I can help with Apache stdcxx packages for Solaris 10. Apache stdcxx on Solaris is only supported for the Studio 12 or higher compilers, and only on Solaris 10 or subsequent Solaris 10 Update Releases. So no need to worry about older versions of Solaris or the Studio compilers. --Stefan ----------- [1] For variable definitions of "free". -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com

On Tue, Dec 7, 2010 at 22:14, Dean Michael Berris <mikhailberis@gmail.com> wrote:

Oh darn. So I guess it's up to me to try and rebuild all the other libraries the app depends on to use either STLPort or Apache stdcxx. If that can't happen, I guess I'm DOA with using Boost on Solaris. :(

I think the only other C++ library dependency for building Boost is ICU. But ISTR that the needed Solaris ICU library -- libicuuc -- doesn't link against libCstd at all, it only links with libCrun, so you might not have to rebuild ICU at all. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman@gmail.com

Dean Michael Berris wrote:

On Wed, Dec 8, 2010 at 11:07 AM, Stefan Teleman <stefan.teleman@gmail.com> wrote:

...

Hi. My answers inline.

On Tue, Dec 7, 2010 at 20:41, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

Okay, as I understand it the STL that Sun uses (libCstd) is a RogueWave derived STL -- which subsequently is the same library which became Apache stdcxx. Is stdcxx the new default or is libCstd still the default with later versions of the compiler/OS? Yes, libCstd is in fact a very old version of RogueWave. But it's so old, it is not ABI compatible with the latest Apache stdcxx V4 (I think libCstd is based on RogueWave Version 2). And it was initially severely crippled due to the C++ compiler limitations in Sun Workshop 5 (yes, it's that old!).The default STL library is still libCstd for the Studio compilers, even for the latest versions (12, 12.1 and 12.2).

Oh darn. So I guess it's up to me to try and rebuild all the other libraries the app depends on to use either STLPort or Apache stdcxx. If that can't happen, I guess I'm DOA with using Boost on Solaris. :(

Maybe not. For a variety of reasons I've been in a position lately to try forcing some parts of Boost to work with studio 12 (on Solaris 10) and the old RW based stl instead of stlport. Here's some notes on that w.r.t boost 1.43. Overall, the compiler is fine -- it has a modern front end and can handle modern c++. It's just the old library that gets in the way. Practically speaking this means that some basic things like shared_ptr, optional, and tuple will work with no difficulty. Just don't try to run the tests...more on that later. The first issue boost build. Compiler options have to be hacked to turn off stlport in tools/sun.jam file -- there may be a more elegant way, but I couldn't figure it out, so I hacked it there. One of the primary issues with the RW based library is lack of a sufficient standard allocator (I believe the it is a missing rebind method). This is easily worked around by simply writing your own allocator and providing it to your favorite boost libs that need an allocator. I actually changed the boost collection defaults in the libs we are using (things like unordered) so that we could use them 'normally' -- basically in a forward compatible mode so we can remove our changes later when we get to a more modern library without impacting boost client code. The library also lacks wide char support -- so I turned that off in boost/config/user.hpp (BOOST_NO_STD_WSTRING and BOOST_NO_STD_WSTREAMBUF). That helped with libraries like string_algo, regex, date-time, and serialization which all have macros that can turn off wide char support. date-time also needed the 'pre-133 facet' (a legacy implementation selected by defining USE_DATE_TIME_PRE_1_33_FACET_IO) since the library I/O facets aren't really up to snuff. This turns off some of the fancy features in date-time i/o, but really not too bad. For filesystem there was a tweak needed in operations.cpp. There was some ambiguity in several places where the sun compiler wanted 0L or 0LL instead of a plain 0. There are probably a few more details, but my experience is that much useful code can be enabled with a little bit of work. That said, there is risk and effort going down this path. Many of the tests for the various libraries won't build even if the library code will b/c tests often depend on other parts of the std lib than the library itself and hence it's often hard to evaluate if a library will work or not. And beyond that, sometimes there is a feature of a lib that won't compile-- but if it's in template code (typical with boost) and you don't use that feature you're fine. We've resorted to subsetting the tests or writing a simple test to evaluate if a library will do what we need it to. And note that all of what I've said is in a way preliminary -- we have used various parts of the aforementioned libs in our own way, but most of it isn't in full production yet. So, depending on the libs and features you need, ymmv. Overall though, in my experience, it's been well worth it for us to do this little bit of effort for the capabilities we've got in return. Jeff