Boost, their build system and Solaris

Thursday, October 1st, 2009 | General

Today I had the experience of trying to modify the boost build system (boost 1.35.0) to adapt to a specific environment of mine – a temporary Solaris environment. Boost’s build system is really quite err… different. I’m not sure if “sucks” is the right word. I would need to get a complete understanding of how it all works before I would be confident using bad words about it. For such a useful and good library, I never expected just getting it to build to be such a problem.

Most people won’t have the problem I’m having since I think it might work out-of-the-box for a “common” system like Linux or their package management system has installed it for them. For me, however, I wanted to do two thing:

  • Add some extra compiler flags to specify the correct CPU architecture
  • Make sure the Sun linker was correctly detected instead of boost using the g++ frontend to do the linking. The command line options are incorrect.

Seems simple enough? Well the problem when you roll-your-own build systems like this is that it differs from the standard conventions. So you can’t use any knowledge or experience to fix this. You have to suddenly learn something new. This shouldn’t be the case for a standard library.

For example, just overriding CPPFLAGS, CFLAGS or CXXFLAGS on the command line had absolutely no effect despite the fact that the configure script said it would. And where do you set the linker easily … ? Well, you cant.

However, I managed to combine knowledge I acquired from several different sites to get this working.

http://www.pion.org/files/pion-platform/common/doc/README.solaris
http://blogs.sun.com/sga/entry/how_to_build_boost_1
http://shoaibmir.wordpress.com/2009/08/12/building-boost-under-solaris/

Each of which has some useful piece of information. And so I did the following… I made sure the prefixes and everything were set up.


./configure --prefix=<path> LDFLAGS="-L<path>" CPPFLAGS="-I<path>"

(Not sure of the CPPFLAGS or LDFLAGS were honoured, I didn’t check.) And then this generates a “user-config.jam” file in the top directory. I modified mine as follows:


# Boost.Build Configuration
# Automatically generated by Boost configure

# Compiler configuration
using gcc : : : <compileflags>-mcpu=v9 <linker-type>sun ;

# Python configuration
using python : 2.3 : /usr/sfw ;

If you don’t specify the CPU architecture, you get warnings from the assembler (as) about the opcode “cas” being incorrect for the architecture – applicable to v9′s instead of v8′s ‘cos “cas” is atomic on v9′s. “(Requires v9|v9a|v9b; requested architecture is v8.)”. And then ….


make

viola. Easy, huh? No …. not at all. The above represents several hours of work. I’m not even sure that it’s the “correct” way to do it.

2 Comments to Boost, their build system and Solaris

durand
October 1, 2009

PS. You might want to modify the default “configure” script to make sure BJAM_CONFIG inherits from the environment. For example:

< BJAM_CONFIG=""
> BJAM_CONFIG=”$BJAM_CONFIG”

Then you can pass through bjam variables and settings during the configuration step. For example:

BJAM_CONFIG=”–layout=system –build-type=complete” ./configure –prefix=/road/to/nowhere

I wasn’t sure before but now I am: this build system sucks.

durand
October 1, 2009

Also:

1) the 1.35.0 build doesn’t properly detect the presence or absence of the ICU libraries. It says they’re there when they are not. So make sure you don’t compile with them in. (./configure –without-icu).

2) The python code doesn’t compile properly with weird errors. I don’t know why and right now I don’t care. (./configure –without-libraries=python)

Leave a comment