GNU bug report logs - #14404
regexp_exec thread-unsafe

Previous Next

Full log

Message #14 received at 14404 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14404 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org
Subject: Re: regexp_exec thread-unsafe
Date: Mon, 20 May 2013 16:20:08 +0200

Paul Eggert <eggert <at> 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?

Thanks!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.