Re: [Boost-build] no matching thread constructor using boost_thread built with STLport

Subject: Re: [Boost-build] no matching thread constructor using boost_thread built with STLport
From: Damjan Zemljiè (damjan.zemljic_at_[hidden])
Date: 2012-04-16 12:52:01

Hi,
our code is actually a plug-in (first level) (with own plug-ins - second
level) for and app created with gcc 3.4 + STLport + boost 1.33.1 (boost
version which we would really like to avoid because of limited shared_ptr
API). We just stepped down from the position, where cross-compiler gcc
4.2.4 and boost 1.35.0 was used for the first and second level plugins.

It is actually quite a Frankenstein (one of the second level plugins is gcc
4.2 with STL (not STLport!), but should be on safe side talking pure "C"
with the rest, hopefully) and we decided to step down and reduce the risks
as much as possible and hopefully get rid off some weird bugs (runtime
linker does not unload the first level plugin cleanly, even though it
claims it does so, which is obvious next time the plugin is loaded and
link-chaos begins).

Initially, code was written for BOOST 1.34.1 (with STL, not STLport) and is
widely used and thoroughly tested. And yes, I know I'm talking about very
old libraries.

To go back to issue, I probably don't understand your point. 1.34.1 holds
declaration in header file but no definition of it?? What I'd suspect is a
naming / namespace issue with the functor allocator referenced, but this is
more or less just a guess... :(

Thank you for a fast response,
Damjan

2012/4/16 Vicente Botet <vicente.botet_at_[hidden]>

>
> Damjan Zemljič wrote
> >
> > Hi,
> > I'm trying to build app which uses some shared library (BMS) depending on
> > boost_thread:
> > - gcc 3.4.3 on Linux 32bit (native build - no cross compilation)
> > - boost 1.34.1 + STLport 5.0
> >
> > Boost is build from scratch with STLport like this:
> > ./bjam -a -j 8 stdlib=stlport threading=multi --without-python stage
> >
> > tools/build/v2/tools/stlport.jam is modified slightly to disable
> > libstlport.so suffixes (two lines outcommented appending _gcc and/or
> > _stldebug) rather to modify the target machine.
> >
> > BOOST builds fine (not everything, spirit for example, but it's not used
> > in
> > the app so I didn't bother). However, building an app reports unresolved
> > symbol, which should be in boost_thread library. Build scripts are ok -
> > used in the past with BOOST and native STL (and they work with BOOST 1.35
> > +
> > STLport!), libraries are found... here is a part of app build command
> > line:
> >
> > usr/bin/c++   -O3 ...  -o bms_ctrl -rdynamic -L/paths...
> > -lboost_thread-gcc34-mt-p-1_34_1 ...
> >
> > Which reports an error:
> > BMS/lib/Linux-2.6/libBMS.so: undefined reference to
> >
> `boost::thread::thread(boost::function0&lt;void,stlp_std::allocator&lt;boost::function_base&gt;
> >> const&)'
> >
>
> Boost.Thread >= 1.35  doesn't defines this prototype and it it included a
> big change. I don't remember if 1.34 did it. I guess you know, we are
> developing 1.50.
>
>
>
> > Analysing the libboost_thread-gcc34-mt-p-1_34_1.so I couldn't found
> > anything similar to undefined symbol referenced in BMS library:
> > ' U
> >
> _ZN5boost6threadC1ERKNS_9function0IvN8stlp_std9allocatorINS_13function_baseEEEEE'
> >
>
> This seems to be the missing overload ;-)
>
>
>
> >
> > If possible (problem is solved), we would prefer boost 1.34.1 over
> 1.35.0.
> > Any idea / hint is very much appreciated.
> >
> >
>
> Have you checked with other platform/compiler/lib?
> I will try to recover the version 1.34.1 and see what could be wrong.
>
> Best,
> Vicente
>
> --
> View this message in context:
> http://boost.2283326.n4.nabble.com/no-matching-thread-constructor-using-boost-thread-built-with-STLport-tp4561861p4561962.html
> Sent from the Boost - Build mailing list archive at Nabble.com.
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>