Subject: bug#14404: regexp_exec thread-unsafe

From: [email-masked] (Ludovic Courtès)
Date: Mon, 20 May 2013 16:20:08 +0200

Paul Eggert <[email-masked]> 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’.