[cfe-dev] libstdc++ Windows port

[Matthew Faithfull]

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.


On 08/03/2012 15:20, Howard Hinnant wrote:
> 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
>
> On Mar 8, 2012, at 10:14 AM, Matthew Faithfull wrote:
>
>> 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.
>>
>> On 08/03/2012 15:00, Howard Hinnant wrote:
>>> On Mar 8, 2012, at 9:28 AM, Matthew Faithfull wrote:
>>>
>>>> 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
>>>
>>>
>