[xsd-users] Specifying location of boost when building from all-in-one package

Charles Grant cegrant at uw.edu
Thu Jan 24 22:08:52 EST 2013


Hi Boris,

On Jan 24, 2013, at 6:26 AM, Boris Kolpackov <boris at codesynthesis.com> wrote:

> 
> Can you verify a few things:
> 
> 1. You are doing a full rebuild.

I did 'make clean' between builds. Is that sufficient?

> 2. Can you check if the required Boost libraries are actually in
>   $HOME/projects/crux-percolator/src/external/lib?
> 
>   Oftentimes, Boost library names include suffixes that contain
>   various information like compiler name and version, etc. If
>   that's the case, then you will need to use the BOOST_LIB_SUFFIX
>   variable to specify the suffix.


The libraries are there. The script that builds boost for us also adds links that remove the suffixes. The libraries are there with both names. For example:

/net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libboost_filesystem-gcc46-mt-s.a
/net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libboost_filesystem-mt-s.a@
/net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libboost_filesystem.a@

On the problematic system the boost libraries in /usr/lib/lib64 don't have the suffix. Interestingly enough if I set

BOOST_LIB_SUFFIX=--gcc46-mt-s

the XSD build no longer finds the library in /usr/lib/lib64, and does find the correct library in 

/net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib

Unfortunately that doesn't provide a solution for us. All of this is all in service of distributing our source to users, and we can't rely on the libraries in /usr/lib/lib64 not having suffixes.

It really looks like the XSD build is checking some standard library locations before it checks the ones in the LDFLAGS. 

Many thanks,

Charles





More information about the xsd-users mailing list