bug-gnulib
[Top][All Lists]
Advanced

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

Re: How to circumvent MinGW's broken pthread_cond_broadcast()


From: Tim Rühsen
Subject: Re: How to circumvent MinGW's broken pthread_cond_broadcast()
Date: Sun, 01 Oct 2017 21:21:49 +0200
User-agent: KMail/5.2.3 (Linux/4.12.0-2-amd64; KDE/5.37.0; x86_64; ; )

On Samstag, 30. September 2017 23:18:20 CEST Tim Rühsen wrote:
> On Samstag, 30. September 2017 20:08:46 CEST Bruno Haible wrote:
> > Tim Rühsen wrote:
> > > My question: How can I force the MinGW build to ignore pthreads and use
> > > the
> > > native Win32 API ? (I am using gnulib's bootstrap script + ./configure,
> > > make, make check.)
> > 
> > Did you try the --enable-threads=windows option, provided by the
> > 'threadlib' module?
> 
> Didn't know about that, very handy.
> 
> Sadly, the build fails with:
> 
> 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,
>  ^
> Makefile:1905: recipe for target 'fatal-signal.lo' failed
> make[3]: *** [fatal-signal.lo] Error 1
> make[3]: *** Waiting for unfinished jobs....
> In file included from /usr/share/mingw-w64/include/signal.h:10:0,
>                  from ./signal.h:52,
>                  from sig-handler.h:21,
>                  from sig-handler.c:3:
> ./signal.h:593:1: error: expected identifier or '(' before numeric constant
>  _GL_FUNCDECL_SYS (pthread_sigmask, int,
>  ^
> 

FYI, it builds with this sequence
PREFIX=x86_64-w64-mingw32
export CC=$PREFIX-gcc-win32
export CXX=$PREFIX-g++-win32
export CPP=$PREFIX-cpp-win32
export RANLIB=$PREFIX-ranlib
./configure --build=x86_64-pc-linux-gnu --host=$PREFIX

I have not found any docs about this, it was just out of intuition (a lucky 
punch).

The cond_broadcast hang doesn't occur any more - interestingly Win32 threads 
seem to have a different switching behavior than pthreads. Now I see a second 
hang which likely comes from a flaw in my code. I'll track  this down in the 
next days.

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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