Help needed (MinGW)

[Tim Rühsen]

Hi,

I currently see during MinGW build:

CC fatal-signal.lo
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
from fatal-signal.c:26:
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^

Any idea what is going on here, it's in the gnulib area ?


With Best Regards, Tim

[Bruno Haible]

Hi Tim,

Post by Tim Rühsen
CC fatal-signal.lo
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^
Any idea what is going on here, it's in the gnulib area ?

The usual tips for such an error:

1) Does it still occur after you did "make distclean", then reconfigure
and "make"?

2) Use CC="gcc -no-integrated-cpp" to get higher quality diagnostics from GCC.

3) Run "make V=1" to see the actual compilation command line. [1]
Then modify that command line to add -E instead of -c -o options, and
redirect that preprocessor output to a file. Analyze it.

Bruno

[1] https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html

[Tim Ruehsen]

Post by Bruno Haible
Hi Tim,

Post by Tim Rühsen
CC fatal-signal.lo
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^
Any idea what is going on here, it's in the gnulib area ?

1) Does it still occur after you did "make distclean", then
reconfigure
and "make"?
2) Use CC="gcc -no-integrated-cpp" to get higher quality diagnostics from GCC.
3) Run "make V=1" to see the actual compilation command line. [1]
Then modify that command line to add -E instead of -c -o options, and
redirect that preprocessor output to a file. Analyze it.

The problem stays (I am now on a second machine, but same system Debian
unstable).

After stripping off the compiler options, the command line is

x86_64-w64-mingw32-gcc-win32 -DHAVE_CONFIG_H -I. -I..
-I/home/tim/src/wget2/x86_64-w64-mingw32/include -no-integrated-cpp
-DNDEBUG -fno-PIC -MT fatal-signal.lo -MD -MP -MF .deps/fatal-
signal.Tpo -c fatal-signal.c -DDLL_EXPORT -DPIC -o .libs/fatal-
signal.o

In the -E output there is
# 593 "./signal.h" 3
extern int 0

;

Line #593-594 in signal.h is:
_GL_FUNCDECL_SYS (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t
*old_mask));

I am using glthreads.
Maybe that has to do with the configure flag --disable-threads !?
The glthread functions are defined a 0 in this case.

The surrounding code in signal.h looks like
#if 1
# if 0
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# undef pthread_sigmask
# define pthread_sigmask rpl_pthread_sigmask
# endif
_GL_FUNCDECL_RPL (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t
*old_mask));
_GL_CXXALIAS_RPL (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t
*old_mask));
# else
# if !0
_GL_FUNCDECL_SYS (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t
*old_mask));
# endif
...

Any more ideas / hints ?

Regards, Tim

[Bruno Haible]

Post by Tim Ruehsen
In the -E output there is
# 593 "./signal.h" 3
extern int 0
;
_GL_FUNCDECL_SYS (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t
*old_mask));

It looks like there is a definition
#define pthread_sigmask(how,newmask,oldmask) 0
somewhere. Gnulib does not contain such a definition of pthread_sigmask.
Therefore I guess that it comes from the mingw header files. How does
the definition/declaration of pthread_sigmask look like, in the mingw header
files?

Bruno

[Tim Rühsen]

 


With Best Regards, Tim

Post by Bruno Haible

Post by Tim Ruehsen
In the -E output there is
# 593 "./signal.h" 3
extern int 0
;
_GL_FUNCDECL_SYS (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t
*old_mask));

It looks like there is a definition
#define pthread_sigmask(how,newmask,oldmask) 0
somewhere. Gnulib does not contain such a definition of pthread_sigmask.
Therefore I guess that it comes from the mingw header files. How does
the definition/declaration of pthread_sigmask look like, in the mingw header
files?

Content of /usr/share/mingw-w64/include/pthread_signal.h:

#ifndef WIN_PTHREADS_SIGNAL_H
#define WIN_PTHREADS_SIGNAL_H

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

#endif /* WIN_PTHREADS_SIGNAL_H */


Regards, Tim

[Bruno Haible]

Post by Tim Rühsen

Post by Bruno Haible
It looks like there is a definition
#define pthread_sigmask(how,newmask,oldmask) 0
somewhere. Gnulib does not contain such a definition of pthread_sigmask.
Therefore I guess that it comes from the mingw header files. How does
the definition/declaration of pthread_sigmask look like, in the mingw header
files?

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

Thanks, it's clear now.

This patch is similar to how we treat similar situations for 'dirfd' and
'strdup'.


2018-01-04 Bruno Haible <***@clisp.org>

pthread_sigmask: Avoid compilation error on mingw.
Reported by Tim Rühsen <***@gmx.de>.
* lib/signal.in.h (pthread_sigmask): Don't declare it it's defined as a
macro.

diff --git a/lib/signal.in.h b/lib/signal.in.h
index 483413d..7d4927b 100644
--- a/lib/signal.in.h
+++ b/lib/signal.in.h
@@ -137,7 +137,7 @@ _GL_FUNCDECL_RPL (pthread_sigmask, int,
_GL_CXXALIAS_RPL (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t *old_mask));
# else
-# if !@HAVE_PTHREAD_SIGMASK@
+# if !(@HAVE_PTHREAD_SIGMASK@ || defined pthread_sigmask)
_GL_FUNCDECL_SYS (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t *old_mask));
# endif

[Tim Rühsen]

Post by Bruno Haible

Post by Tim Rühsen

Post by Bruno Haible
It looks like there is a definition
#define pthread_sigmask(how,newmask,oldmask) 0
somewhere. Gnulib does not contain such a definition of pthread_sigmask.
Therefore I guess that it comes from the mingw header files. How does
the definition/declaration of pthread_sigmask look like, in the mingw header
files?

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

Thanks, it's clear now.
This patch is similar to how we treat similar situations for 'dirfd' and
'strdup'.

Thanks Bruno,

sorry, but now the build hangs at

In file included from /usr/share/mingw-w64/include/signal.h:10:0,
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)


Regards, Tim

[Bruno Haible]

Hi Tim,

Post by Tim Rühsen
sorry, but now the build hangs at
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
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)

Do you have time to provide a patch for this?

Hint: Look how this situation is handled in the modules 'dirfd' and 'strdup'.

Bruno

[Tim Rühsen]

Post by Bruno Haible
Hi Tim,

Post by Tim Rühsen
sorry, but now the build hangs at
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
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)

Do you have time to provide a patch for this?
Hint: Look how this situation is handled in the modules 'dirfd' and 'strdup'.

Sorry, no time to look at it any deeper. And a general solution is not
obvious from strdup.c or dirfd.c.

IMO, pthread_sigmask.c shouldn't be relevant with --disable-threads and
thus either not being used or code skipped by

#if defined USE_POSIX_THREADS || defined USE_PTH_THREADS || defined
USE_SOLARIS_THREADS || defined USE_WINDOWS_THREADS

or similar.

I assume, I don't get the whole concept here (at least not by looking 5
mins at it).

Anyways, I attached a diff that works for me. It's definitely not a
general solution but I can continue to work around a threading issue in
wine / mingw that hangs a project's CI runner.


Regards, Tim