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

From: Nicholas Cain (nik.cain.boost_at_[hidden])
Date: 2004-08-31 03:11:41

Nicholas Cain wrote:

> 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)?
> ...

Something just crossed my mind - while looking at the bjam build with 
the -d+2 set, it seemed to have all the stlport paths etc.

Does boost build with the gcc-stlport setting redefine _STL as std, and 
so even though the examples have std:: in them, it's really STLPort? 
(and I shouldn't be doing using namespace _STL)?

nik