Adding support for mingw-w64 and winpthread

[Johannes Pfau via D.gnu]

Am Thu, 24 Mar 2016 11:12:20 +0100
schrieb "Iain Buclaw via D.gnu" <d.gnu at puremagic.com>:

> On 24 March 2016 at 10:52, Vincent R via D.gnu <d.gnu at puremagic.com>
> wrote:
> 
> > Hi,
> >
> > I would like to generate gdc compiler on msys2/mingw-w64 platform.
> > The build system on msys2 uses archlinux build architecture and the
> > build file is here:
> >
> > https://github.com/vrichomme/MINGW-packages/blob/newfastrelease/mingw-w64-gcc/PKGBUILD
> > [...]
> >  
> 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.

It supports most of the pthreads API IIRC but there are sometimes
complaints about performance of the wrapper code. It basically only
wraps windows primitives to the pthread API. It's even legal to mix
winpthreads and windows API code.

Some new C++11 (or 14) features are only supported by libstdc++ with
the pthread API. This is the main reason why MinGW compilers use the
winpthread code, nobody has written a native std::thread implementation
for MinGW yet.

However, I think for D the best solution is to always use the windows
API. Upstream druntime takes care of this anyway so this means less
work for us.

> 
> >
> > 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.
> 

And the details are kinda complicated. In this specific case though,
the interesting part is this:

* --enable-threads=X sets the GNU_Thread_Model=X variable in gcc.config
* For windows / posix, we use version(MinGW) or
  version(Windows) / version(Posix).


So in this case you end up with the combinations:
version (Windows)
{
    import gcc.config;
    static if(GNU_Thread_Model == ThreadModel.Posix)
       //winpthreads
    else static if(GNU_Thread_Model == ThreadModel.Win32)
       //native
}

version(Posix) is not set and should not be set!




I also had another look at MinGW-W64 some weeks ago but then got
distracted :-)

Here's a quick patch to get winpthreads working:
https://paste.gnome.org/pl3pqzcke


This only hooks up the gthreads API with winpthreads. But when
implementing this quick workaround, I realized there are two open
questions:

* We could probably use the standard windows gthread implementation,
  even if the GCC model is set to pthreads. AFAICS the only place we
  use gthreads is in rt.monitor for the class monitors and it doesn't
  matter if we use the windows API directly or the wrapper. We could
  probably even merge gcc/gthreads into the rt module, much of
  gcc.gthreads isn't even used anymore.
* This patch doesn't expose the fact that a pthread emulation layer is
  available to user code (i.e. you can't use the core.sys.posix.*
  pthread modules). I don't think we need to expose this as we have
  cross-platform wrappers in core.thread/core.sync anyway.

So the main question is: can we simply ditch gcc.gthreads and inline
the code into rt.monitor?