[cfe-dev] anyone knows the current state of libc++ on windows?

Reid Kleckner rnk at google.com
Mon May 12 15:38:28 PDT 2014


I think that page is mostly about Clang's MSVC compatibility, not libc++'s
usability on Windows.  I think http://libcxx.llvm.org/ would be a better
place to talk about Windows support for libc++.

One day, when Clang, libc++, and lld work together, we can put together
some kind of holistic toolchain and document how it all fits together there.


On Mon, May 12, 2014 at 4:08 AM, Dennis Luehring <dl.soluz at gmx.net> wrote:

> does it make sense to update the page
>
> http://clang.llvm.org/docs/MSVCCompatibility.html
>
> with these information you gave - it seems that the current clang/llvm
> capabilities are not overall known
> - or is the windows compatiblity currently a too fast moving target for
> status update on this detail level
>
> same question goes to Reid Kleckner
>
>
> Am 08.05.2014 18:04, schrieb G M:
>
>  Hi I've only just noticed this discussion. I don't have time to add to it
>> /
>> follow it now but I will tomorrow..
>>
>> In the mean time, here's a few things I know that might be useful, not in
>> answer to any particular question.
>>
>> libc++ doesn't yet compile fully with MS's cl compiler or visual studio.
>> That's because of library and language issues.
>>
>> cl can't handle some language constructs like static constant member
>> variables that g++ and clang++ support. That's a show stopper. When cl.exe
>> gets constexpr this will likely be solvable.
>>
>> MSVC doesn't have a full c-library, so libc++ on it's own isn't that
>> useful
>> if using MS's libraries (as opposed to mingw compatible versions). If you
>> build libc++ with Visual Studio, it will fail because some functions
>> libc++
>> declares clash with MS versions. This could be fixed but I haven't
>> bothered
>> because until cl supports the missing language constructs necessary libc++
>> still won't build.
>>
>> libc++ needs pthread support, MSVC's C library doesn't have that. An
>> initial pthread library was contributed a while back, possibly by Nico
>> (though I may be wrong), but it was withdrawn or never followed up on. I
>> never hard back when I inquired why. mingw does have pthread support.
>>
>> libc++ expects a C library atomic support (I think) on which it bases it's
>> own atomic<> support. MS don't provide that.
>>
>> libc++ does build on Windows with g++ (or did until very recently if
>> not) and mingw and does build with clang++ and mingw. If you have problems
>> using g++ and libc++ on windows and it's a std::string inline function
>> error, Marshall is aware of it, but I don't know the latest.
>>
>> clang-cl might be something to try if you're used to MS's cl, it might
>> have
>> better default options for use on Windows than clang++ but I haven't tried
>> it.
>>
>> Sorry, gotta run now. Will try to follow this more tomorrow. Hope this
>> helps.
>>
>>
>>
>> On Fri, May 9, 2014 at 1:19 AM, Dennis Luehring <dl.soluz at gmx.net> wrote:
>>
>> > Am 08.05.2014 14:59, schrieb Yaron Keren:
>> >
>> >  Why use the combination of: clang compiler & Visual C++ link & Visual
>> C++
>> >> C
>> >> headers & libcxx C++ headers ?
>> >>
>> >
>> > i thought this would be the base for an MinGW free libc++/clang on
>> Windows
>> > clang as my c++ compiler using an libc++ build with clang based on msvc
>> > c-runtime headers/lib
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140512/179509aa/attachment.html>


More information about the cfe-dev mailing list