Re: [Boost-users] Solaris Sun Studio 12, boost 1.44 - choosing version of STL

Subject: Re: [Boost-users] Solaris Sun Studio 12, boost 1.44 - choosing version of STL
From: Jeff Garland (azswdude_at_[hidden])
Date: 2010-11-22 10:03:22

Vladimir Prus wrote:
> Paulo Moura Guedes wrote:
> 
>> Hi,
>>
>> I want to use the standard Solaris STL libCstd, so I'm using the
>> "stdlib=native" switch in bjam. However, stlport4 is being picked up.
>>
>> How can I force boost not to use stlport4?
> 
> No, because Jamroot has this:
> 
>       # The standard library Sun compilers use by default has no chance
>       # of working with Boost. Override it.
>       <toolset>sun:<stdlib>sun-stlport
> 
> I suspect that the "no chance" in the comment still holds.

Well, it's not 100% true. For a variety of reasons I've been in a position 
lately to try forcing some parts of Boost to work with the delivered sun 
libraries instead of stlport.  I had to hack the compiler options in 
tools/sun.jam file to make it work cause I didn't find/understand the line 
above and how to change it.

One of the primary issues with the sun delivered 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 so that we 
could use them 'normally' -- basically in a forward compatible mode. The sun 
provided libs also lack wide char support -- so I turned that off in 
boost/config/solaris.hpp. That helped with libraries like string_algo, regex, 
and date-time which all have macros that can turn off wide char support. There 
  are probably a few more details, but my experience is that much useful code 
can be enabled with a little bit of work.

All 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 sunsetting the tests or writing a simple test to 
evaluate if a library will do what we need it to. So far, 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.

HTH,

Jeff