Solaris Sun Studio 12, boost 1.44 - choosing version of STL

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? Thanks in advance, Paulo

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. - Volodya

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
participants (3)
-
Jeff Garland
-
Paulo Moura Guedes
-
Vladimir Prus