[cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

[writeonce at midipix.org]

On 09/24/2014 10:30 AM, Óscar Fuentes wrote:
> "writeonce at midipix.org"
> <writeonce at midipix.org> writes:
>
>> One important point you seem to be missing is the ability to
>> cross-compile API/CRT software on Windows with a clang.exe which does
>> not depend on msvcrt.exe.
> Why we would want to do that? (Moreover, considering that LLVM/Clang is
> expected to work with MSVC++ which, obviously, depends on msvcrt as
> MinGW does.)
For those primarily interested in building clang on Linux from a 
possibly modified development trunk, for instance, there could be a 
considerable advantage in using the same libc when building clang for 
Windows.  And if you are interested in debugging the toolchain itself, 
then several additional advantages come to mind (using strace, using 
conforming shell tools, etc.)

>>   From a technical perspective (and also with
>> respect to many of its goals), the project differs from Cygwin in
>> virtually every possible way (some key differences, as well as the
>> distinction between mingw as a target and a libc++ _for_ mingw, can be
>> found in my original message).
> Let's see. Suppossing a LLVM/libClang that uses that libc on Windows, my
> software that links to LLVM/libClang must use libc too, right?
The example you gave here treats clang, the compiler, and clang, the 
library, as being one and the same thing.  For me they are not, at least 
not functionally; accordingly, I find that the above use case falls 
under the category 'libClang for mingw/msvc', rather than 'clang on 
Windows'.

The above notwithstanding, it looks like the issue in hand is probably 
quite smaller than it first seemed to be, and that a solution is already 
in the making.  If the limitations of msvcrt had not (yet) created an 
actual void, then, there is also no (current) necessity for a posix libc 
to fill it.