views:

1105

answers:

3

My development shop has put together a fairly useful Python-based test suite, and we'd like to test some Linux-based C++ code with it. We've gotten the test project they ship with Boost to compile (type 'bjam' in the directory and it works), but we're having issues with our actual project.

Building the boost libraries and bjam from source (v1.35.0), when I run bjam I get a .so in the bin/gcc-4.1.2/debug directory. I run python and "import " and I get: ImportError: libboost_python-gcc41-d-1_35.so.1.35.0: cannot open shared object file: No such file or directory

Looking in the library directory, I have the following: libboost_python-gcc41-mt-1_35.so libboost_python-gcc41-mt-1_35.so.1.35.0 libboost_python-gcc41-mt.so

Obviously I need the -d instead of the -mt libraries, or to point at the -mt libraries instead of -d, but I can't figure out how to make my Jamroot file do that.

When I install Debian Etch's versions of the libraries, I get "No Jamfile in /usr/include" - and there's a debian bug that says they left out the system-level jamfile.

I'm more hopeful about getting it working from source, so if anyone has any suggestions to resolve the library issues, I'd like to hear them.

Response to answer 1: Thanks for the tip. So, do you know how I'd go about getting it to use the MT libraries instead? It appears to be more of a problem with bjam or the Jamfile I am using thinking I am in debug mode, even though I can't find any flags for that. While I know how to include specific libraries in a call to GCC, I don't see a way to configure that from the Boost end.

+2  A: 

One important Point: -d means debug of course, and should only be linked to a debug build of your project and can only be used with a debug build of python (OR NOT, SEE BELOW). If you try to link a debug lib to a non-debug build, or you try to import a debug pyd into a non-debug python, bad things will happen.

mt means multi-threaded and is orthogonal to d. You probably want to use a mt non-d for your project.

I am afraid I don't know how to tell gcc what to link against (I have been using Visual Studio). One thing to try:

man gcc

Somewhere that should tell you how to force specific libs on the linker.

EDIT: Actually you can import a debug version of you project into a non-debug build of python. Wherever you included python.h, include boost/python/detail/wrap_python.hpp instead.

Matthew Scouten
+2  A: 

If you want to build the debug variants of the boost libraries as well, you have to invoke bjam with the option --build-type=complete.

On Debian, you get the debug Python interpreter in the python2.x-dbg packages. Debug builds of the Boost libraries are in libboost1.xy-dbg, if you want to use the system Boost.

Torsten Marek
+2  A: 

Found the solution! Boost builds a debug build by default. Typing "bjam release" builds the release configuration. (This isn't listed in any documentation anywhere, as far as I can tell.) Note that this is not the same as changing your build-type to release, as that doesn't build a release configuration. Doing a 'complete' build as Torsten suggests also does not stop it from building only a debug version.

It's also worth noting that the -d libraries were in <boost-version>/bin.v2/libs/python/build/<gcc version>/debug/ and the release libraries were in <gcc-version>/release, and not installed into the top-level 'libs' directory.

Thanks for the other suggestions!