anyone knows the current state of libc++ on windows?

the information on http://libcxx.llvm.org/results.Windows.html seems to be a little bit out-dated

anyone still working on the port?

Hi Dennis,

You can build libcxx using MingW-w64

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/

but not using Visual C++.

Yaron

but not using Visual C++.

sorry for my unprecise question

libc++ & MingW
   compiles (as you wrote) - and all tests run fine?

libc++ & MSVC
   does not compile - what parts, any building/test stats available?

libc++ & Clang under Windows
   ???

Hi Dennis,

I routinely compile libc++ & libcxxabi with clang as compiler and link with MinGW 4.8.2 (gcc calling ld) as an replacement for libstdc++. It builds and overall works. I have run the tests some while ago, most passed but there were failures, have not looked in depth.

libc++ compiled with gcc - gcc 4.7 could not handle some of the “advanced” C++ code in libcxx. Have not tested with 4.8 or the just released 4.9.

libc++ with Visual C++ - there were multiple C++ compatibility problems even with VC 2013.
Someone named “G M” had tried this for a while and some of his patches were comitted, search on the list for “G M”.
The latest Visual C++ is 2013 Update 2, MS are imporving VC C++ support every version, you can try building libcxx with it and see what fails now. The free express version is available here

http://www.microsoft.com/en-us/download/details.aspx?id=40787

Yaron

I routinely compile libc++ & libcxxabi with clang as
compiler and link with MinGW 4.8.2 (gcc calling ld)
as an replacement for libstdc++.

did you ever checked linking with "Microsoft Visual C Run-Time Library" (MSVCRTxyz)
so that the dependencies are only libc++ & libcxxabi & MSVCRT - is that possible
or are there still compile/link problems with microsoft stuff

MinGW does not have its own C library, it uses MSVCRT for C library.
So practically any program compiled with MInGW depends on MSVCRT.

Yaron

MinGW does not have its own C library, it uses MSVCRT for C library.
So practically any program compiled with MInGW depends on MSVCRT.

but why is then MinGW needed at all - is the MinGW c library in use as an wrapper
or can't clang directly compile(link) agains MSVCRT?

clang (lld) can’t link .o files (COFF) on Windows.
MinGW is needed mainly for ld linker and for the C library headers but also for other libraries, such as the unwinder.

using the MSVC linker would solve llds problem with COFFs - and the Microsoft headers seems to be useable by clang
but i don't known the differences between MinGW C lib headers and microsoft and what is needed for the unwinder

clang can function in two different modes on Windows, MinGW compatible or Visual C++ compatible.
The object formats are not compatible. The Windows installer for LLVM includes a clang toolchain for Visual C++.
There is no ready MinGW-based current clang toolchain available, some based on older clang.

What are you trying to achieve?

clang can function in two different modes on Windows, MinGW compatible or
Visual C++ compatible.
The object formats are not compatible. The Windows installer for LLVM
includes a clang toolchain for Visual C++.
There is no ready MinGW-based current clang toolchain available, some based
on older clang.

What are you trying to achieve?

i just want to find out if its possible to get rid of MingGW using only clang & msvc-link & libc++ & MSVCRT
or if there is much more work needed

I think it mostly works, but not 100%.

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

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.

I think I know what you mean, but I wanted to clarify it a bit.

MinGW and MSVC differ only in the C++ ABI and in passing structs by value
in C. If you limit yourself to COM or extern "C" interfaces that don't
pass things by value, you can link object code from all three compilers,
MSVC, GCC, and Clang, together and it will work. Obviously, this is too
limiting for many users, so Clang has support for both MinGW and MSVC C++
ABIs now.

Is there some other object file level incompatibility that I'm forgetting,
like differing .drectve contents?

If you eliminate MinGW, you will also need Microsoft's Windows SDK for
windows.h.

I don't think anyone has tried this combination of libraries yet. You
would have to use the MSVC++ ABI to avoid generating calls to things like
__cxa_guard_acquire, which are usually provided by MinGW. We don't support
RTTI or exceptions in that ABI yet, though.

Beyond that, I don't think anyone has tried it, so I'm sure some work is
needed to make the pieces fit together perfectly. C11 _Atomic support
comes to mind. Clang has it, but we suppress it in the presence of
-fms-compatibility because it conflicts with the MSVC <atomic> header.

I’m linking C++ code and so had not started testing cross-linking objects due to the different C++ ABI.
The debug information format is completely different, C and C++.
I’m not sure the import library information is the same.
The library support routines are different.
Even with C code I think there will be obstacles to linking objects from Visual C++ and MinGW.
DLLs with C interface do link OK.

I would be interesting to see MinGW and clang converging to Visual C++ object binary compatibility at least for C code. There had been changes in this direction.

so i think there is plenty of work until it works out of the box - thanks for the status update

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

Hi