Brian Webb
I'm trying to build the boost libraries on Ubuntu 8.10 with gcc-4.3.2, and it's a mess! I think there are more failed compiles than there are successes. Is there something that I'm missing, or is this currently unsupported?
This is the compile command that I'm using:
bjam --toolset=gcc --prefix=$PREFIX --layout=system --user-config=`pwd`/user-config.jam stage
This is user-config.jam:
using gcc : : g++ : <compileflags>-I/swl/ix86-linux/include <linkflags>-L/swl/ix86-linux/lib ; using mpi ;
Any pointers would be appreciated.
Pointers to what? There's no "building Boost on Ubuntu" guide, in part beca use it just works. You did not give a single error message, and did not explain why you're adding some scary include and linker paths.
Thanks for the help. It turns out that the problem was the "scary include and linker paths." I'm using those to find dependencies (bzip2, zlib, python, etc) in non-standard directories. As it turns out, there was an older version of boost (1.34.1) in those directories. Apparently the older boost include files were getting picked up prior to the new ones. Is there a better way of adding additional include and library paths that will insert the paths in the correct order? Just removing the old version appears to be working, but I would like to know the correct way of doing this if there is a better way.
Use -I and -L options which will come before the -I's and -L's for boost 1.34.1. For example, if you're building 1.38 in ~/1.38 and your 3rd party dir is `/swl', then you'd want a compile command that looked like this: g++ -I${HOME}/1.38/include -I/swl/include ... likewise with the linker: g++ [opts] -o whatever [objs] -L${HOME}/1.38/lib -L/swl/lib In short, the options given are searched in order. A better solution would probably be to rm the old boost, though. HTH, -tom