<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/23/2014 09:02 PM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0Kh8z-hTnrC238e6DOd-ZpkhrZx5px3m4O_dEWXFZ4CDjg@mail.gmail.com"
type="cite">
<div dir="ltr">AKA: MinGW + win32threads is holding LLVM (and all
of its subprojects) back. We need to stop supporting this host
platform.
<div><br>
</div>
<div>I'm aware of essentially 2 reasonably important use cases
for supporting MinGW + win32threads:</div>
<div><br>
</div>
<div>1) Sane host toolchain on Windows that doesn't require
downloading MSVC. (I'm dubious about the value of this one...)</div>
<div><br>
</div>
<div>2) Cross-compiling a Windows clang.exe (and other tools)
from a Linux (or other host) box.</div>
<div><br>
</div>
<div>Are there others? (And thanks to Reid for explaining these
to me!)</div>
<div><br>
</div>
<div><br>
</div>
<div>I'm somewhat dubious about #1, but if we address #2 it will
address any concerns with #1 anyways.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
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.<br>
<br>
* portable means that the project <span class="moz-txt-underscore"><span
class="moz-txt-tag">_</span>does not<span class="moz-txt-tag">_</span></span>
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.<br>
<br>
** 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.<br>
<br>
additional technical and general information<br>
-----------------------------------------------------------<br>
The principals of the project that are probably the most relevant to
clang/llvm are:<br>
<br>
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.<br>
<br>
2. provide a tightly integrated development framework consisting of
a libc, a compiler (gcc, clang), and a user-space sub-system (the
terminal emulator).<br>
<br>
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).<br>
<br>
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).<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
zg<br>
<br>
</body>
</html>