[cfe-dev] libc++ for Windows

[Ruben Van Boxem]

2011/1/1 Michael Spencer <bigcheesegs at gmail.com>:
> On Fri, Dec 31, 2010 at 6:36 AM, Ruben Van Boxem
> <vanboxem.ruben at gmail.com> wrote:
>> Hi,
>>
>> I was wondering if there are plans (in the near future/today) to "port"
>> libc++ to the Windows platform? This would make the project a lot more
>> useful than it is right now, as clang is starting to get better at Windows
>> stuff.
>>
>> PS: How would I go about building libc++ on Windows right now (to see if I
>> can get the rough edges off before the serious work starts).
>>
>> Thanks!
>>
>> Ruben
>
> Howard is fully welcoming patches for Windows support. I ported libc++
> to CMake (already in tree) and have started working on Windows support
> (not in tree). I have about %25 of it compiling, however, the changes
> I made were mainly just to get it to compile (not necessarily run) so
> that I could figure out what needs to be done for a proper port.
>
> My current plan (not the official plan) for porting in general is to
> design and implement a constraint based configuration language to
> generate C Preprocessor code that does the actual compiler/platform
> checks to present a full POSIX 2008 API for the rest of the library to
> use.
>
> - Michael Spencer
>

Thanks for the answer and presumably good news that Windows is getting
some love too in libc++ :)

I do have one concern though: exposing a full POSIX API that is
Windows API-based has already been done, with the necessary
performance caveats and is still not (feature?)complete. Look at
Cygwin, which tries to implement a POSIX sublayer for Windows.

I believe that in contrast to GCC's C and C++ libraries, libc++ has
the possibility to implement a (full) native source for all the
library functions. I would also believe this would be the best in
terms of performance. Let me clarify: Cygwin vs MinGW: Cygwin uses a
"slow" POSIX sublayer and is more compatible to that effect. MinGW
uses the MS runtime libraries, which gives MinGW programs a tremendous
speed advantage over their Cygwin counterparts. What I say is this:
use the MS runtimes in a transparent way, so that only the "broken"
functions that need fixing are reimplemented in libc++ and the Clang C
library. I don't know how the C part is currently handled in Clang,
but please don't make the same mistake that GCC made: assume some
POSIXy inbetween layer and write an additional platform abstraction
for that.

The prime example is this: GCC's std::thread support. Internally, GCC
uses a __gthread API, which is pretty much a 1:1 mapping of posix
threads. Therefore, MinGW either needs pthreads-win32 (which is a
hateful project that is very necessary and dead as a volcanic rock)
to enable OpenMP and other multithreaded support. This is awful...
There is some work on the way to reimplement pthread API in the
mingw-w64 runtime, and some work to implement std::thread in Windows
native API. This last bit is exactly what needs to be done IMHO. Why
the next abstraction anyway. Additionally: Clang has the advantage
that it is already written in C++ and that for example the OpenMP
implementation can benefit from stuff like the <thread> library from
C++0X, if done right. Heck, std::thread can just be copied from the
boost Windows implementation I would think (if there aren't all too
many boost-specific dependencies though).

I hope I haven't stirred up any dark conflicts or old discussions. I
know my knowledge on the subject is limited, but I don't think my
ideas are so far-fetched.

Thanks for reading!

Ruben

PS: I'll be glad to do some minor testing, as I said: I have limited
knowledge on the subject, but have thought about these things quite
hard and long.