[lldb-dev] [cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
writeonce at midipix.org
writeonce at midipix.org
Wed Sep 24 04:27:26 PDT 2014
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
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev