Adding support for mingw-w64 and winpthread

[Vincent R via D.gnu]

On Thursday, 24 March 2016 at 10:12:20 UTC, Iain Buclaw wrote:
> How readily does Mingw support pthreads? What may be needed is 
> simply a new package for mingw-specific system functions (ie: 
> core.sys.mingw.pthread). In the meantime, you should be able to 
> get around by passing --enable-threads=win32 when configuring 
> teh gcc build.
>
>
>>
>> But how is defined this value ? Is it based on uname function 
>> ? Can I trace the value of version when compiling the file ?
>>
>>
> What versions that are internally defined depend on the target 
> triplet passed when configuring the build.  This directly 
> affects what target headers are included, which contain macros 
> we call when initializing the compiler.
>
> It has been requested even in DMD to have some command-line 
> option to print all turned on version conditions set by the 
> compiler.  Itself is a very trivial addition.  In the absence 
> of that though, in a debugger you can set a breakpoint on 
> VersionCondition::addPredefinedGlobalIdent.
>
> Iain.


> How readily does Mingw support pthreads? What may be needed is 
> simply a new package for mingw-specific system functions (ie: 
> core.sys.mingw.pthread). In the meantime, you should be able to 
> get around by passing --enable-threads=win32 when configuring 
> teh gcc build.

winpthread is defined here:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/include/
So winpthread is just a normal pthread.h include file and mingw 
compiler include a corresponding library.


Thanks for the information about --enable-threads=win32 and 
that's what I used to do but now I don't want to use that kind of 
trick and I would like to generate a posix version because as 
long as it doesn't support it, it will never be considered as a 
valid package from msys2/mingw-w64 maintainers.