bug-gnulib
[Top][All Lists]
Advanced

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

Re: pthread_sigmask and glibc


From: Eric Blake
Subject: Re: pthread_sigmask and glibc
Date: Tue, 02 Aug 2011 14:39:49 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.11

On 08/02/2011 02:33 PM, Paul Eggert wrote:
On 08/02/11 11:12, Eric Blake wrote:
AC_CHECK_FUNCS_ONCE does not add the mandatory -pthread compiler
switch, and glibc only provides pthread_sigmask when compiling for
threads.  This seems fishy to me; it seems like we have a bug in
pthread_sigmask.m4 for not recognizing glibc's version, and
populating $(LIB_PTHREAD_SIGMASK) with -pthread as appropriate.

pthread_sigmask depends on threadlib, which means this shouldn't be a problem.
threadlib arranges for -pthread (or whatever) as needed.

GNU Emacs avoids threadlib, and arranges for -pthread (or whatever)
itself.  But that's fine: packages that avoid threadlib are supposed
to know what they're doing.

But the point is that even with the threadlib module and selection of posix threads, we are getting ac_cv_func_pthread_sigmask=no and subsequent rpl_pthread_sigmask on glibc, even though we don't need the replacement in that case. There's a bug in the m4 file for using AC_CHECK_FUNCS_ONCE without the right flags pre-determined by havelib.m4, but I'm not sure how best to fix it.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]