bug-gnulib
[Top][All Lists]
Advanced

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

Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock


From: Tim Rühsen
Subject: Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock
Date: Fri, 12 Apr 2019 09:15:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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