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

[writeonce at midipix.org]

On 09/23/2014 09:02 PM, Chandler Carruth wrote:
> AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) 
> back. We need to stop supporting this host platform.
>
> I'm aware of essentially 2 reasonably important use cases for 
> supporting MinGW + win32threads:
>
> 1) Sane host toolchain on Windows that doesn't require downloading 
> MSVC. (I'm dubious about the value of this one...)
>
> 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux 
> (or other host) box.
>
> Are there others? (And thanks to Reid for explaining these to me!)
>
>
> I'm somewhat dubious about #1, but if we address #2 it will address 
> any concerns with #1 anyways.
>
> I would like to propose that we finish implementing libc++ 
> sufficiently to host Clang on Windows using native Windows APIs to 
> implement things. Then we document very clearly what is required to 
> download the basic Windows SDK and cross compile Clang (and any other 
> tools) for Windows using just libc++ and the SDK. No need for MSVC 
> bits, etc. Would this be acceptable?
>
> If not, would it be acceptable to use libc++ on top of mingw (so just 
> avoiding libstdc++)? I *really* don't want to spend lots of time going 
> there because it seems like a low-value platform, but we can.
>
> Anyways, I want to tease out anything else required here because if 
> this is all we need, I think we can make it a reality and get to a 
> much saner platform.
>
>

To address #1 in a somehow unorthodox manner: musl libc is expected 
become available on NT at the end of 2014, or very early in 2015. Once 
available, portable[*] projects that successfully build against musl on 
linux (which occasionally requires a few patches, mostly due to a 
project working around bugs in popular libc's in strange and mysterious 
ways) should successfully build and execute on NT without any 
source-level modifications.[**]  Below is additional technical and 
general information about the project.

* portable means that the project _does not_ use esoteric PRCTL codes 
and their liking.  The midipix system layer does provide common 
facilities such as /proc, /dev/random, /dev/tty, /dev/pty, etc., so 
using them in a program or library should not create for a problem.

** a well-written portable project should only need to add appropriate 
references to the midipix targets (x86_64-nt64-midipix, 
i686-nt32-midipix) to its build system.  In addition, gui projects might 
need to divorce WIN32 from GDI.  In other words, projects that want to 
use musl libc in conjunction with GDI will need to ensure that their 
#ifdef's do not conflate the system api with the gui framework of interest.

additional technical and general information
-----------------------------------------------------------
The principals of the project that are probably the most relevant to 
clang/llvm are:

1. "portability from below": make the libc available on NT by providing 
its prerequisites (the system call layer, the tty facility, /proc, etc.) 
rather than changing it.  This means that save a few 
architecture-specific files, the libc source for NT and Linux are 
identical, and accordingly free of #ifdef hackery.

2. provide a tightly integrated development framework consisting of a 
libc, a compiler (gcc, clang), and a user-space sub-system (the terminal 
emulator).

3. allow executables to be distributed with zero external dependencies 
(copy your application and the terminal emulator to a folder, along with 
any other libraries or data files that your application might need, and 
you are all set).

4. provide ultimate flexibility with respect to the GUI framework being 
used (to answer a popular question: a terminal emulator does not 
necessarily mean an open terminal window).

Once the above goals have been met, it would be possible to have a 
native clang/llvm development environment on NT that could be used both 
natively and for cross-compilation .  At the same time, it is important 
to realize that as far as mingw(-w64) goes, cross-compilation itself 
will _not_ (and cannot) solve the current mingw shortcomings with 
respect to libc++, or any of the issues related to its dependencies (see 
Chandler's #1).

As far as existing code bases are concerned, the projects that could 
benefit from the midipix framework the most are cross-platform projects 
that prefer a linux/posix api (and libc) over the WIN32 one.  Projects 
that are purely written for WIN32 could still benefit from the 
development environment, however in order to benefit from the libc (or 
any other feature) at run-time, some effort and refactoring will have to 
be in place.

Last but not least: although the midipix project is currently reaching 
its advanced development phase prior to an alpha release, and while it 
is planned to be released with an OSI-compatible license, the vast 
majority of the code is not yet publicly available.

Regards,
zg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/56957aab/attachment.html>