[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: weak _pthread_mutex_lock()



Hello!

On Fri, Jul 27, 2007 at 04:55:15PM +0200, Michael Banck wrote:
> On Mon, Jul 16, 2007 at 09:31:04PM +0200, Samuel Thibault wrote:
> > Is there still a reason for _pthread_mutex_lock() to be weak? 
> 
> Hrm, when I recompile openexr with hurd-dev_20070606-2, I now get:
> 
> g++ -pipe -g -Wall -O2 -o eLut eLut.o
> eLut.o: In function `pthread_mutex_init':
> /usr/include/bits/mutex.h:81: undefined reference to
> `_pthread_mutex_init'
> eLut.o: In function `__pthread_mutex_trylock':
> /usr/include/bits/mutex.h:120: undefined reference to
> `_pthread_mutex_trylock'
> eLut.o: In function `__pthread_mutex_lock':
> /usr/include/bits/mutex.h:108: undefined reference to
> `_pthread_mutex_lock'
> collect2: ld returned 1 exit status
> make[2]: *** [eLut] Error 1
> make[2]: Leaving directory `/build/buildd/openexr-1.2.2/Half'

It seems to me that this is the same issue which stops us from having a
recent version of GNU gettext and with I reduced down to this tiny test
case already some months ago:
<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00097.html>.

If I remember my findings at that time correctly, then the issue is
essentially that due to the inline functions from <bits/mutex.h> (and
friends) some unwanted things are going on if later ``-lpthread'' is
_not_ being passed when linking.  As Neal told me that these inline
functions are just an optimization which he copied (when writing
libpthread) from Mark Kettenis' code, perhaps just removing them would
already help?

Also, we should evaluate Bruno Haible's suggestions from
<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00102.html>.

Roland, Samuel: you know this (p)threading stuff best of us all; what do
you suggest?


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature


Reply to: