Building Boost 1.34.1 on Solaris 10/SPARC
According to http://blogs.sun.com/sga/entry/boost_mini_howto "upcoming
Boost 1.34 works with Sun C++ well out of the box" - can anyone confirm
this? I'm trying to upgrade from Boost 1.33.1 to Boost 1.34.1 on Solaris
10/SPARC but ran into problems with both CC (Sun C++ 5.9 SunOS_sparc Patch
124863-01 2007/07/25) and g++ 3.4.6.
With "./bjam --toolset=sun stage" I see this error (among others):
sun.compile.c++ bin.v2/libs/wave/build/sun/debug/threading-multi/instantiate_cpp_exprgrammar.o
"./boost/wave/util/flex_string.hpp", line 529: Error: Formal argument 2 of
type void* in call to std::allocator<char>::allocate(unsigned, void*) is
being passed const char*.
"./boost/wave/util/flex_string.hpp", line 558: Where: While
instantiating "boost::wave::util::AllocatorStringStorage
Hello Boris,
On 10/3/07, Boris
According to http://blogs.sun.com/sga/entry/boost_mini_howto "upcoming Boost 1.34 works with Sun C++ well out of the box" - can anyone confirm this? I'm trying to upgrade from Boost 1.33.1 to Boost 1.34.1 on Solaris 10/SPARC but ran into problems with both CC (Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25) and g++ 3.4.6.
With "./bjam --toolset=sun stage" I see this error (among others):
I think you need to compile with STLPort instead of Sun's default STL
implementation for boost. Check out Simon's newer postings regarding
boost on Solaris http://blogs.sun.com/sga/category/Boost .
I was able to compile boost 1.34.1 on Solaris 10 (sparc) using Sun C++
5.9 as well as gcc 3.4.6.
1. For Sun C++ 5.9: I can't remember if I had to change any jam
configs but here are the bjam command-line options I've used:
/path/to/boost-build/bin/bjam --build-dir=/path/to/build.suncc12 \
--stagedir=/path/to/stage.suncc12 \
toolset=sun
stdlib=sun-stlport -j2 -d2 stage
2. For gcc 3.4.6: You need to create a user-config.jam file with the
following settings (adjust the compiler flags to your arch,
$BOOST_SRC_ROOT is the directory were the extracted boost source
resides):
cat > $BOOST_SRC_ROOT/user-config.jam <
On Wed, 03 Oct 2007 17:34:59 +0300, Sebastian Hauer
[...]I think you need to compile with STLPort instead of Sun's default STL implementation for boost. Check out Simon's newer postings regarding boost on Solaris http://blogs.sun.com/sga/category/Boost .
I was able to compile boost 1.34.1 on Solaris 10 (sparc) using Sun C++ 5.9 as well as gcc 3.4.6.
1. For Sun C++ 5.9: I can't remember if I had to change any jam configs but here are the bjam command-line options I've used:
/path/to/boost-build/bin/bjam --build-dir=/path/to/build.suncc12 \ --stagedir=/path/to/stage.suncc12 \ toolset=sun stdlib=sun-stlport -j2 -d2 stage
Thanks for your help! I could build Boost 1.34.1 successfully - stdlib=sun-stlport did the trick. After reading a comparison between libCstd and libstlport at http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html it might be a good idea for Boost to automatically choose stlport when Boost is built on Solaris? Boris
Boris wrote:
Thanks for your help! I could build Boost 1.34.1 successfully - stdlib=sun-stlport did the trick. After reading a comparison between libCstd and libstlport at http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html it might be a good idea for Boost to automatically choose stlport when Boost is built on Solaris?
Yes, but the better sulution is for sun to do it in their compiler. They can let users select the old library as an option if they need the backword compatibillity. As it seems to me Sun has no plans to get that library fixed, so why keep it as default? -- Bjørn
On Thu, 04 Oct 2007 07:41:44 +0300, Bjørn Roald
Boris wrote:
Thanks for your help! I could build Boost 1.34.1 successfully - stdlib=sun-stlport did the trick. After reading a comparison between libCstd and libstlport at http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html it might be a good idea for Boost to automatically choose stlport when Boost is built on Solaris?
Yes, but the better sulution is for sun to do it in their compiler. They can let users select the old library as an option if they need the backword compatibillity. As it seems to me Sun has no plans to get that library fixed, so why keep it as default?
If there are no plans for Sun to fix their old library no Boost user on Solaris will be able to build Boost out of the box as you always have to select stlport explicitly? That doesn't mean I don't sympathize with your idea of switching the default library on Solaris - but I don't think that it's going to happen as backward compatibility seems to be really important to them. Boris
participants (3)
-
Bjørn Roald -
Boris -
Sebastian Hauer