From: Nicholas Cain (nik.cain.boost_at_[hidden])
Date: 2004-08-24 10:50:45
David Abrahams wrote:
>goochrules! <goochrules_at_[hidden]> writes:
>
>
>
>>On Mon, 23 Aug 2004 23:32:14 +0200, Nicholas Cain
>><nik.cain.boost_at_[hidden]> wrote:
>>
>>
>>>I saw yours and Davids posts, and thought it looked the same, but then I
>>>realised yours was std::allocator< ... etc, while mine is
>>>_STL::allocator<... . I find that when I use the normal std everything
>>>works, but not when I try to use STLPort, so I'm confident I'm linking
>>>to the libraries, but they don't
>>>contain_STL::allocator<boost::function_base>
>>>I don't know if this is a problem in the way I built boost or STLPort,
>>>or with my makefile or environment.
>>>
>>>thanks for noticing though!
>>>
>>>nik
>>>
>>>
>>I've seen this exact problem on Windows, in various forms: basically
>>one of a) the application I was working on or b) boost was not linked
>>against STLPort, but with the STL included with the compiler.
>>
>>To confirm this I looked at the dependencies of my project and the
>>boost libraries (depends.exe on Windows, "otool -L" on OS X, otherwise
>>"nm -j a.out | c++filt -_" and "nm -j a.out | c++filt-n" have been
>>helpful.
>>
>>To solve this I specifically added the path the the STLPort includes
>>(.h) first in the extra includes list (CFLAGS) and the path to the
>>STLPort libraries (.[dll|dylib|so|a]) first in the extra libaries list
>>(LDFLAGS).
>>
>>
>
>When you build the Boost libraries for use with STLPort, pass the -d+2
>option so you can see the command lines bjam issues. Make sure you
>replicate the STLPort-related -D options when compiling your own code.
>In particular, one of those options has an impact on what namespace
>the standard library ends up in.
>
>The most reliable way, of course, is to use Boost.Build to build your
>own project and reference the Boost project libraries. That will
>always make sure the options are compatible.
>
>
>
After a day of persistence I've got my projects to build with bjam,
although I still get the error:
undefined reference to
`boost::thread::thread[in-charge](boost::function0<void,
_STL::allocator<boost::function_base> > const&)'
However, I'm not sure that I'm implementing your last suggestion
properly. Do I just have a dependency on the libboost_thread shared
object, and Boost.Build figures it out the options, or do I need to
bring in something from the threads src folder (like threads.jam or
something)?
- at the moment my bjam files look like;
-------in /Development --------
project mainProj
: requirements <threading>multi
<include>/usr/include/python2.3
<include>/usr/local/include/stlport
<include>Common
<include>Common/ErrorReporting
<include>/usr/local/include/boost-1_31
<include>/home/ncain/xerces-c-src_2_5_0/include ;
build-project Core/XMLConfigParser ;
build-project Core/ScriptingInterface ;
build-project Core/TimedVariableQueue ;
----------------------------------
-------in /Development/Core/TimedVariableQueue/--------
project theTimedVariableQueue ;
lib TimedVariableQueue
: TimedVariableQueue.cpp :
<include>../XMLConfigParser ;
build-project TimedVariableQueueUnitTests ;
----------------------------------
-------in
/Development/Core/TimedVariableQueue/TimedVariableQueueUnitTests----------
project theTimedVariableQueueUnitTest ;
exe TimedVariableQueueUnitTest
: TimedVariableQueueUnitTest.cpp
/usr/local/lib/libstlport_gcc.a
/usr/local/lib/libxerces-c.so
../../../lib/XMLConfigParser.so
/usr/local/lib/libboost_thread-gcc-mt-p.so
TimedVariableQueue.so : (that's a
lazy sym link in the unittests folder)
<include>../../TimedVariableQueue
<include>../../XMLConfigParser ;