Open pfmoore opened 2 weeks ago
The winlibs attempt to build LLVM uses the GCC standard libraries in order to allow both toolkits to be used interchangeable. However this is probably not a good idea.
LLVM comes with its own standard libraries and I would really recommend using the builds from https://github.com/mstorsjo/llvm-mingw
If you recommend not using them, perhaps you should document them as such on winlibs.com.
And put the without-clang builds before with-clang.
Thanks. I was using this because it's really hard to find a good build of LLVM for Windows. The ones from the LLVM site use the MSVC standard C library, and broke horribly because I have a project that needs C++11, and the MSVC libs no longer support C++11. So I picked the winlibs build because I was already using it for gcc.
I'll look into the mstorsjo builds as an alternative, and switch to the without-clang builds from here.
The winlibs attempt to build LLVM uses the GCC standard libraries in order to allow both toolkits to be used interchangeable. However this is probably not a good idea.
LLVM comes with its own standard libraries and I would really recommend using the builds from https://github.com/mstorsjo/llvm-mingw
Oof, unless I just missed it (and it's possible) it'd be really nice to have this stated up front on releases.
Here's a simple reproducible example, using "GCC 14.2.0 (with POSIX threads) + LLVM/Clang/LLD/LLDB 18.1.8 + MinGW-w64 12.0.0 UCRT - release 1" (64-bit version).
hw.cpp:
Compile with
clang++ -o hw.exe .\hw.cpp
and everything works fine.objdump
shows it links at runtime tolibstdc++-6.dll
.However, if you try to build a statically linked executable, using
clang++ -o hw.exe -static .\hw.cpp
the linker thows a series of errors:This is particularly frustrating, as I have no need of threads. And it's worth noting that the non-static build did not link to
libwinpthread-1.dll
, so the compiler obviously recognises that there's no need for thread support.