On 09/24/2014 10:30 AM, Óscar Fuentes wrote:
"writeo...@midipix.org"
<writeo...@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.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
