[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
signature.asc
Description: OpenPGP digital signature
- Tests on MinGW: undef ref pthread_mutex_lock/unlock, Tim Rühsen, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Bruno Haible, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Tim Rühsen, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Bruno Haible, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Tim Rühsen, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Tim Rühsen, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Bruno Haible, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Eric Blake, 2019/04/11
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock,
Tim Rühsen <=
- Re: Tests on MinGW: undef ref pthread_mutex_lock/unlock, Bruno Haible, 2019/04/13