Can anyone fill me in on the status of pthreads dependency in stdc++. As far as I can tell the current situation is as follows:-
The libstdc++ Windows port uses MinGW, MinGW doesn't have pthreads support out of the box, so do we need a special MinGW?
The obvious alternative, installing 'pthreads for Windows', doesn't work due to that project being out of date (2006) and the fundamental types being incompatible. for example pthread_t is a struct under ptw32 and a pointer under OSX.
Using the OSX pthreads header(s) may enable compilation to complete ( I haven't tried it ) but would then need a new OSX ABI compatible port of pthreads to Windows in order to work. Is this in the works or are there other plans afoot to get around the issue?
A full new Windows port of pthreads is by my very approximate reckoning a minimum 3 months full time work so I'm not about to jump in if it isn't going to be useful.
Do you mean libc++ (http://libcxx.llvm.org/)?
My recommendation would be to map the C++11 <thread>/<condition_variable>/<mutex> to the native Windows API as closely as possible, rather than go through the additional pthreads abstraction layer.
Howard
Yes I do mean,
libc++ (http://libcxx.llvm.org/)?
I got pinged for calling it libstdcxx in a previous post due to confusion with the old Apache project. I'll get it right eventually 
I agree that a Windows implementation relying on pthreads does not look like a good idea so we need an implementation of C++11 <thread> etc on top of the Windows API.
How would you see this sitting within the libc++ project structure. It would be a rather large lump of platform specific code, without a current precedent. Would a seperate Windows C++11 concurrency library be preferable?
Matthew F.
We currently have both include/support/win32 and src/support/win32. I would imagine a continuation of that strategy. I would also recommend porting <chrono> first (the clocks) so that the pieces of threading that depend on timing fall into place.
Howard
Thanks, that looks like a great idea as a starter. <chrono> is close to building but not quite there. support/win32 is fine, I'll follow the existing code wherever possible.
I have 3 days off next week with internet but no car so I hope to be able to get into it properly then.
I notice the current support/win32 code pulls in for example <xlocinfo.h> I'd like to confirm where this is coming from as it doesn't seem to be supplied by MinGW and the Microsoft Platform SDK version is clearly licensed 'All Rights Reserved' which would I presume prevent it from being used under the llvm BSD style license. I've no interest in starting a legal argument here I'm just wanting to confirm #include paths for an external dependency.
Matthew F.
libstdc++ is the GNU project. Do you mean libc++?
Sebastian
There was some discussion of this on the list a while ago, but I don't think anyone got as far as implementing anything. Ruben Van Boxem has done most of the Windows work so far, so it would be worth checking with him. I plan on adding support for Windows exceptions to libcxxrt once LLVM can generate working Win64 EH tables (I'm not really interested in 32-bit, but patches are welcome...)
David
Sorry for resurrecting a few-month-old thread, but I’m curious about the current status of the Windows version of libc++. From this and other threads, it seems the library should be buildable using mingw-w64, but I am immediately hitting missing header file errors when compiling (notably pthread.h). It seems like mingw32 has the pthread bits while mingw-w64 does not, yet mingw-w64 has the xlocinfo.h header file while mingw32 does not; so neither distribution is sufficient in itself.
I realize the Windows version is far from complete and not necessarily surprised by these issues, I would just like to know the current status (what should be working), and where effort is currently being spent.
By the way, I was using GIT head from a couple of hours ago.
Ping… anyone know the status of this?