Il 20/05/2013 16:20, Ludovic Courtès ha scritto: > Paul Eggert <egg...@cs.ucla.edu> skribis: > >> On 05/14/2013 02:21 PM, Ludovic Courtès wrote: >> >>> How should that be fixed? Shouldn’t __libc_lock_unlock & co. be rebased >>> on top of pthread_mutex_t? >> >> Yes, thanks, that sounds right. I pushed the following patch into gnulib; >> could you please see whether it fixes the problem for you? It'd be >> helpful to try it on non-glibc systems too, if possible. > > Thank you for the quick reply. I haven’t tested yet, but I have a question: > >> --- a/modules/regex >> +++ b/modules/regex >> @@ -24,6 +24,7 @@ memmove [test $ac_use_included_regex = yes] >> mbrtowc [test $ac_use_included_regex = yes] >> mbsinit [test $ac_use_included_regex = yes] >> nl_langinfo [test $ac_use_included_regex = yes] >> +pthread [test $ac_use_included_regex = yes] >> stdbool [test $ac_use_included_regex = yes] >> stdint [test $ac_use_included_regex = yes] >> wchar [test $ac_use_included_regex = yes] > > Seems like this is going to add -lpthread to LDFLAGS, right? > > That would raise two issues: first, it should add -pthread to both > CFLAGS and LDFLAGS, not just -lpthread. > > Second, Guile can be compiled with and without thread support. In the > latter case, we wouldn’t want Gnulib to stealthily pull in pthreads. > How can this be addressed?
Use the lock module instead. Paolo
