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.
I've not looked at this, but it's worth noting that supporting the pthread API on Windows is MUCH easier if you are willing to break XP compatibility. Microsoft introduced a new set of primitives with Vista that mean that you no longer need the complex userspace stuff to implement the various POSIX synchronisation primitives that weren't properly supported by Windows. These should also be expressive enough for most of the C++0x threading stuff if used directly, so supporting Vista+ is likely to be much easier than supporting XP and earlier.
David
-- Sent from my PDP-11
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
Ruben Van Boxem <vanboxem.ruben@gmail.com>
writes:
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...
You are being very pessimistic about libc++ development pace and very
optimistic about OS replacement rate 
If previous experience is worth anything, we can bet that on 2015 will
be millions of machines running XP, both for personal use on developing
countries and on business-related roles everywhere.
[snip]
Support for any system in an open source project depends on someone being willing to either do it themselves or pay someone else to do it (the latter being the reason why Apple typically has good support from LLVM-related projects).
A number of thread-related classes (e.g. std::condition_variable) are significantly easier to implement using Vista-or-later APIs, so if I were going to implement Windows versions of them (I won't be - I don't have a Windows machine anymore) I'd be inclined not to bother supporting XP.
If someone wants to write a version that works with Windows XP, then I doubt anyone would object to it, but I suspect that code that exists and requires Vista will be more popular than code that doesn't exist and supports XP / 2K.
Another option is to use mingw-pthreads for XP and provide a native version for Vista+.
David
-- Send from my Jacquard Loom