On 09/21/10 03:43, Bruno Haible wrote:
> The modules 'lock', 'tls',
> etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
> Basically, every piece of code that wants to provide multithreaded
> access to a global variable (may it be a registry or cache or anything)
> needs locking.
Yes, but the problem is that coreutils does not need and does not want
that multithreaded access, and yet it has to build the multithreaded
support anyway. The runtime cost is probably small, but it introduces
dependencies and porting problems that are not worth the hassle. And
I worry that it may cause unreliability at runtime, on some platforms.
It'd be better if applications could say "I don't need gnulib to be
multithread-safe, and please don't bother with thread-safety"
when it incorporates library code from gnulib. Even 'sort', the only
coreutils program that is multithreaded, doesn't need the gnulib code
itself to be thread-safe.
>> + AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])
>
> It would be wise to include <pthread.h> here. Not all systems define
> these types in <sys/types.h>; some (e.g. mingw pthreads-win32) require
> a #include <pthread.h>. This include is not part of AC_INCLUDES_DEFAULT.
Thanks, I'll incorporate the following further patch in my next suggestion.
I don't think this'll affect Gary's problem.
--- old/m4/pthread.m4 2010-09-21 00:25:57.628643000 -0700
+++ new/m4/pthread.m4 2010-09-21 10:03:50.638754000 -0700
@@ -15,7 +15,11 @@ AC_DEFUN([gl_PTHREAD_CHECK],
HAVE_PTHREAD_H=0
fi
- AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])
+ AC_CHECK_TYPES([pthread_t, pthread_spinlock_t], [], [],
+ [AC_INCLUDES_DEFAULT[
+ #if HAVE_PTHREAD_H
+ #include <pthread.h>
+ #endif]])
if test $ac_cv_type_pthread_t != yes; then
HAVE_PTHREAD_T=0
fi
