Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-05-26 18:38:25


Christoph Ludwig wrote:
> On Thu, May 26, 2005 at 03:10:56PM -0500, Rene Rivera wrote:
>
>>Patrik Jonsson wrote:
>>
>>>Rene Rivera wrote:
>>>
>>>
>>>>Well that's a single threaded library, it would have "threading-multi"
>>>>in the path if it was multi threaded.
>>>>
>>>>
>>>>>ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock
>>>>>ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock
>>>>>ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init
>>>>>ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy
>>>>
>>>>
>>>>
>>>>It's likely that something other than Boost requires pthread. Could
>>>>you find out what that is? It could be libstdc++, or something else..
>>>>
>
> [...]
>
>>But more generally I would think that it should not generate *any*
>>locking code when doing a single threaded build.
>
>
> What happens if you build with BOOST_DISABLE_THREADS explicitly defined? Maybe
> the problem discussed in GCC PR#11953
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953> exists on AIX as well?
> (It's only a wil guess since (a) I haven't seen the thread Rene's posting
> belongs to and(b) I don't have access to an AIX system.)

It's a thread from the user list. But I quoted basically all of it.

> The effect of PR#11953 under Linux is similar to what you report: The standard
> library defines _REENTRANT in some header included by shared_ptr.hpp which
> makes the smart_ptr library require some pthread symbols - even if you do a
> single threaded build. AFAIK the only workaround is to define
> BOOST_DISABLE_THREADS.

OK, read that PR. It certainly does look like the problem. Peter already
suggested, in the user list, that using BOOST_DISABLE_THREADS is the way
to "fix" it.

Thanks :-)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk