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