[cfe-dev] libc++ for Windows

[Ruben Van Boxem]

2011/1/28 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
> 2011/1/1 Michael Spencer <bigcheesegs at gmail.com>:
>> On Sat, Jan 1, 2011 at 6:11 AM, Ruben Van Boxem
>> <vanboxem.ruben at gmail.com> wrote:
>>> 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.
>>
>> One of the main reasons I wanted to do it this way is because the
>> latest version of the Microsoft C Runtime supports a large subset of
>> POSIX 2008, but a lot of the names are prefixed with _. We don't have
>> to do a full implementation.
>>
>>> 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,
>>
>> There is no Clang C library. libc++ targets the system C library.
>>
>>> 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.
>>
>> Pthreads is one of the APIs that I actually really didn't want to
>> implement for Windows. I'm fine with using the Windows API directly,
>> however, I'd like to share as much code as possible between platforms.
>>
>> To put it simply. I agree that trying to treat Windows like Unix is a
>> bad idea and leads to performance issues. I really just want to have
>> as few preprocessing directives in the main library code as possible,
>> and having a single, consistent API allows that.
>>
>> Thanks for the interest in Windows support!
>>
>> - Michael Spencer
>>

(didn't send this to mailing list :s)

Is it feasible/ok for libc++ to only support vista+? It seems kind of
logical, as that would allow focus on more important windows things
and when libc++ is production ready on Windows, xp will be phases out
imho... Does clang need anything like mingw other than to allow legal
cross-compiling from non-Windows with the Windows SDK? (it isn't
permitted to use this on other OSes) I'm sure mingw-w64 people will be
interested in helping if needed!

Would the fact that the system runtime is used implicate that some C99
features aren't supported on Windows? Or are there only compiler
requirements in C99 vs Windows crt?

I also have opened a set of bugs on the tracker for mingw-w64 support
and more general windows issues as well. I will continue to work as
far as I can in the followinf days and provide patches/workarounds
when possible. (http://llvm.org/bugs/show_bug.cgi?id=9084)

Ruben