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

[G M]

Hi


On Mon, May 12, 2014 at 11:08 PM, 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
>
> When I run the libcxx test suite with mingw I have to use the
-fno-exceptions flag. It would be good to know what kind of road map there
is for getting exceptions working etc. even if it was a very vague one. As
in 2014, 2015? etc.

Is it true that exceptions are an unstarted task?

by the way in the libcxx++ library stuff on windows, I think things like
error_category don't work on Windows - the error code list isn't right for
Windows (from memory) and chrono is a little broken and it needs C11 atomic
and pthread. That's the least of anyone's worries though, it's just another
thing to add to the todo list.

Also, last time I tried to link ms generated import libraries to clang++
object files I got lots of undefined references to `__imp_WhateverFunction'
etc.
I could have been doing something wrong though.

It might be worth while updating the status page with a link to the latest
libcxx test suite result output on windows.



> 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/36914f7d/attachment.html>