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@wanadoo.fr>

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