Am Thu, 24 Mar 2016 11:12:20 +0100 schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> On 24 March 2016 at 10:52, Vincent R via D.gnu <d.gnu@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?
