C++ Frontend Tales

All | Boost | General | Loki
« One more language... | Main | How to build Boost... »

20070406 Friday April 06, 2007

How to compile Boost 1.34 with stlport

Upcoming Boost 1.34 still has not been released. But it is in a very good shape and compatible with Sun C++ without any annoying patches. If you do not want to get it by CVS you can take its CVS snapshot here. Unfortunately there is one, at least one :-) problem with this version. By default it uses libCstd.2.1.1. This leads to enormous number of errors. Are there any workaround? Sure!

  1. Download and unpack tarball. Let's suppose the created directory name is 'boost'.
  2. cd boost
  3. Create in this directory file 'user-config.jam' with following content (spaces are important):
    import toolset : using ;
using sun :  : <path to your Sun C++ compier>/bin/CC : <cxxflags>-library=stlport4 <linkflags>-library=stlport4 ;
  4. Build 'bjam' utility as described here. And put it on your $PATH.
  5. Run bjam --v2 -sBOOST_BUILD_PATH=`pwd` --toolset=sun stage
That's all.
Permalink Comments [8]
Trackback URL: http://blogs.sun.com/sga/entry/how_to_compile_boost_1
Comments:

Hi, Boost 1.34 has tools/build/v2/tools/sun.jam with following contents feature.compose <stdlib>sun-stlport : <cxxflags>-library=stlport4 <linkflags>-library=stlport4 ; I thought that this was same as step 3 ? -- regards, Prashant Thakre

Posted by Prashant on April 16, 2007 at 03:34 PM MSD #

I know about this line in the sun.jam, but by default Boost still use libCstd library. Dou you know how to switch <stdlib> to sun-stlport from the bjam command line?

Posted by Simon on April 16, 2007 at 04:39 PM MSD #

Am afraid not. I tried passing --stdlib=sun-stlport to bjam, but that doesn't help. Guess, will have to ask boost.build mailing list. --

Posted by Prashant Thakre on April 17, 2007 at 11:26 AM MSD #

Is use of stlport mandatory? I'd like to use boost, but my project has thirdparty libraries. If I use stlport, then (I assume) I must ensure that my entire application is built with the same flags, i.e. -library=stlport4. This is a potential issue for me. I must ask the 3rd party vendor to recompile their libraries and I must ensure consistent building of my own source code. Ironically, it may be easier for me to switch to GCC, since that way I can ensure that all C++ code is switched at once. If any modules are accidentally compiled with SunStudio, then name mangling differences would work to my advantage and make the error obvious. Mixing the default STL (libCstd) with STLPort in one executable may not be immediately obvious but is very likely to lead to undefined behaviour. Also, is STLport with SunStudio supported by Sun to the same extent as the default STL library? I'd be interested to hear if there are any plans to get Boost working with the default STL supplied with SunStudio. Thanks, Paul

Posted by Paul on April 17, 2007 at 03:39 PM MSD #

If we implement in the libCstd all functionality necessary for Boost we will break binary compatibility between libCstd and third party libraries. Users will not get any advantages. You are absolutely right - libCstd and stlport4 cannot be mixed. And -library=stlport4 is the only way to work with Boost. Sun provides the same support for libCstd and stlport4 libraries which come with Sun C++ compiler. But please note we do not support http://stlport.org

Posted by Simon on April 17, 2007 at 07:28 PM MSD #

Hello everyone, i am VERY interested in the possibility of compiling bosot 1.34 for ublas... unfortunately on the boost web site it appears that UBLAS and PYTHON are not available... and they are exactly the libraries i use the most :-( does anyone know if this will be fixed? thanks in advance Riccardo

Posted by Riccardo Rossi on April 26, 2007 at 07:42 PM MSD #

Riccardo, I see Python result on this page http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/python_release.html but do not see ublas result. Could you provide a link? In any case I will take a look at these problems.

Posted by Simon on April 26, 2007 at 08:56 PM MSD #

We also have the problem of wanting to use stlport yet having vendor libraries built with libCstd. It is not possible to ask them for a rebuild.
I was thinking that instead we could thinly wrap the vendor library with a proxy and build this as a shared library. The rest of our code could be built with -library=stlport4.
It seems to me that so long as we arrange the link line so that stlport is seen in preference to the wrapped library, the libCstd symbols shouldn't cause a problem. Is this a possibility? If not, what is the problem?

Posted by Richard HIckling on November 02, 2007 at 01:14 AM MSK #

Post a Comment:

Name:
E-Mail:
URL:

Your Comment:

HTML Syntax: NOT allowed