Boost logo

Boost Users :

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


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at