signbit: fix compilation error when gnulib's math.h exists twice

[Bruno Haible]

When a package has two invocations of gnulib-tool, and both lead to a
 override, the two overrides conflict: The first override defines
gl_signbitf, gl_signbitd, gl_signbitld as macros, and the second override
then chokes with error messages such as:

../gnulib-lib/math.h:2858: error: expected identifier or '(' before '{' token
../gnulib-lib/math.h:2859: error: expected identifier or '(' before '{' token
../gnulib-lib/math.h:2860: error: expected identifier or '(' before '{' token


2019-04-12  Bruno Haible  

signbit: Fix compilation error when gnulib's math.h exists twice.
* lib/math.in.h (GNULIB_defined_signbit): New macro.

diff --git a/lib/math.in.h b/lib/math.in.h
index aa03ea3..99a2c6a 100644
--- a/lib/math.in.h
+++ b/lib/math.in.h
@@ -2379,7 +2379,7 @@ _GL_WARN_REAL_FLOATING_DECL (isnan);
 sizeof (x) == sizeof (double) ? __builtin_signbit (x) : \
 __builtin_signbitf (x))
 # endif
-# if @REPLACE_SIGNBIT@
+# if @REPLACE_SIGNBIT@ && !GNULIB_defined_signbit
 #  undef signbit
 _GL_EXTERN_C int gl_signbitf (float arg);
 _GL_EXTERN_C int gl_signbitd (double arg);
@@ -2422,6 +2422,7 @@ _GL_EXTERN_C int gl_signbitl (long double arg);
(sizeof (x) == sizeof (long double) ? gl_signbitl (x) : \
 sizeof (x) == sizeof (double) ? gl_signbitd (x) : \
 gl_signbitf (x))
+#  define GNULIB_defined_signbit 1
 # endif
 # ifdef __cplusplus
 #  if defined signbit || defined GNULIB_NAMESPACE

Re: openmp: add workaround for 32-bit programs on AIX

[Bruno Haible]

> 2019-04-09  Bruno Haible  
> 
>   openmp: Add workaround for 32-bit programs on AIX.

Oops, this code did not compile on platforms without . This fixes it.


2019-04-12  Bruno Haible  

openmp: Fix compilation error on platforms without OpenMP.
* lib/omp-init.c: Include  only if _OPENMP.

diff --git a/lib/omp-init.c b/lib/omp-init.c
index f849067..0256d29 100644
--- a/lib/omp-init.c
+++ b/lib/omp-init.c
@@ -17,8 +17,12 @@
 
 #include 
 
+#ifdef _OPENMP
+
 /* Specification.  */
-#include 
+# include 
+
+#endif
 
 #include 
 

Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock

[Tim Rühsen]

On 12.04.19 02:26, Bruno Haible wrote:
> Hi Tim,
> 
> The points to look at are:
>   - How does the configure script behave while running the expanded code
> that comes from threadlib.m4? Try "sh -x ./configure ..." for this
> exercise.
>   - Why does gl_lock_unlock expand to a call to pthread_mutex_unlock? Only
> if USE_POSIX_THREADS is defined. And where does USE_POSIX_THREADS come
> from on your system?

Well, stderr and stdout seems to mixed up pretty much when using
./configure ... >out 2>&1. So all I can see is that USE_POSIX_THREADS is
being set. [indented code is from threadlib.m4]


if test "$gl_use_threads" = yes || test "$gl_use_threads" = posix; then

+ test -n yes
+ gl_threads_api=posix

  AC_CHECK_HEADER([pthread.h],
[gl_have_pthread_h=yes], [gl_have_pthread_h=no])

+ gl_have_pthread=yes

  if test "$gl_have_pthread_h" = yes; then


if test -n "$gl_have_pthread"; then
  gl_threads_api=posix
  AC_DEFINE([USE_POSIX_THREADS], [1],

+ test -n yes
+ gl_threads_api=posix
+ printf '%s\n' '#define USE_POSIX_THREADS 1'


Little bit further above in the configure output:
+ gl_have_pthread=yes
+ LIBTHREAD=-pthread
+ LTLIBTHREAD=-pthread
+ LIBMULTITHREAD=-pthread
+ LTLIBMULTITHREAD=-pthread
+ rm -f core conftest.err conftest.o conftest.exe conftest.c
+ LIBS=
+ test -n yes
+ break
+ test -n yes
+ test -z -pthread
+ test -z yes
+ test -n yes
+ gl_threads_api=posix
+ printf '%s\n' '#define USE_POSIX_THREADS 1'
+ test -n -pthread
+ case "$gl_cv_have_weak" in


The output is pretty large. If interested, I'll send it to you via PM.

>> In file included from /usr/share/mingw-w64/include/signal.h:10,
>>  from ./signal.h:52,
>>  from pthread_sigmask.c:20:
>> pthread_sigmask.c:34:1: error: expected identifier or ‘(’ before numeric
>> constant
>>  pthread_sigmask (int how, const sigset_t *new_mask, sigset_t *old_mask)
>>  ^~~
>> make[4]: *** [Makefile:10495: pthread_sigmask.o] Fehler 1
> 
> This one, you can start with a "gcc -E" command, to see where a macro
> expansion of pthread_sigmask come from.

As Eric says, pthread_sigmask is defined to 0 in
/usr/share/mingw-w64/include/pthread_signal.h:

/* Windows has rudimentary signals support.  */
#define pthread_sigmask(H, S1, S2) 0

> Btw, I never build with mingw-pthreads installed. But even with mingw-pthreads
> installed, gnulib modules ought to not use it; they ought to use the Windows
> API instead.
> 
> Bruno
> 
> 

Regards, Tim



signature.asc
Description: OpenPGP digital signature