Open FelixBer opened 4 months ago
We don't build/use LLVM's libc. It's a rather recent invention. I don't think it even works on Windows yet?
I know we dont yet, I am wondering what's missing and how we might get there. LLVM's libc isnt receiving much attention on Windows, but as far as I can see the biggest limitation is the full build and the required app startup code.
Since we are using mingw libs for this anyways we dont need the startup code, and it might be possible to just drop in that libc for using its standard functions rather than those of msvcrt.
The website claims libc cant support libc++ yet. But this is a) very old disclaimer and b) probably mostly related to the startup code.
Martin and any other mingw-w64 maintainers would be more familiar with this than I do, but a lot of bits of mingw-w64-crt is designed to work with msvcrt/ucrt, which I think (not really sure?) is intertwined with the CRT startup code, and also possibly SEH handling and etc. What you're going for is replacing mingw-w64-crt with an incomplete libc and I cannot estimate how much of it you can really reuse. That requires experimentation which I personally don't have much interest in at least for now.
Actually, though I don't know how exactly msys2 or cygwin works they both use newlib instead of msvcrt/ucrt. But they have their own CRT startup code which is different from mingw-w64.
When we say LLVM libc doesn't work on Windows, do take our word for it. Sure, nobody probably has tried, but they also know it wouldn't work without a significant effort.
There are many parts of a libc. Higher level generic bits like printf formatting probably is mostly OS independent and might work, but many parts of the libc also ties in closely to the OS underneath (calling the actual kernel to do things), and at that level, there's a mile wide difference between Unix's syscalls and Windows' kernel32.dll.
It's certainly possible to take the LLVM libc, in whichever shape/form it is right now, and make it work for Windows, to replace msvcrt/ucrt, but it would be a large undertaking.
A potentially much more realistic thing to do, would be to take Wine's implementation of msvcrt/ucrt and use that. That already exists and works, and should, these days, be a regular native DLL that should be able to run on native Windows. I'm not sure if it supports being built as a static library instead of as a DLL, but I'm quite confident, that making Wine's msvcrt implementation work as a static library would be one order of magnitude less effort than making LLVM libc work on Windows. Unfortunately, for these cases, Wine's implementation is LGPL, so that somewhat limits in which cases it could be used, though.
Hi,
I understand these toolchains are designed to link dynamically against msvcrt / ucrt, but I am wondering what's missing for fully static C++ linking using Clang/LLVM on Windows and without any microsoft libs (libcmt, libcpmt, libvcruntime, etc.)
Since you take the startup code from mingw, shouldnt the LLVM libc be sufficient to fill in the "gap" between that and libc++? If not, what's missing?
Thanks,