Re: [Boost-users] Re: problem compiling with threads and stlport

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 ;