brechtsanders
What happened to LLVM?
What happened to the builds with LLVM? The last version with LLVM seems to be GCC 14.2.0 + LLVM/Clang/LLD/LLDB 19.1.7 + MinGW-w64 12.0.0, with GCC 14.3 and 15.1 not having a version with LLVM.
Recent versions of LLVM fail to built with GCC, so I'm figuring this out.
But I was never a big fan of having an LLVM with GCC's standard libraries. I believe it's better to use LLVM with it's own standard libraries as its distributed on https://github.com/mstorsjo/llvm-mingw/releases
I'm curious as to why you need it. Is there a good use case of having LLVM (maybe together with GCC) using GCC's standard libraries?
Wasn't aware it was using the GCC standard libraries for LLVM. Was interested just from the perspective of having GCC and LLVM both packaged together in the same MinGW build (easier to deploy, no duplicates of all the other tools, etc).
I don't know if it was a bug on this package, on the other packages out there (like LLVM-MinGW), but the LLVM version you distributed was the one that worked the best for me, as in least bugs.
Recent versions of LLVM fail to built with GCC, so I'm figuring this out.
But I was never a big fan of having an LLVM with GCC's standard libraries. I believe it's better to use LLVM with it's own standard libraries as its distributed on https://github.com/mstorsjo/llvm-mingw/releases
I'm curious as to why you need it. Is there a good use case of having LLVM (maybe together with GCC) using GCC's standard libraries?
Is it fixed in llvm 20 ?
Hi, Fail to build LLVM/CLANG with GCC 15.1.0 ...
How about MSYS2 on Windows ? ->
./clang.exe --version clang version 20.1.7 Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: C:/msys64/mingw64/bin ./gcc.exe --version gcc.exe (Rev6, Built by MSYS2 project) 15.1.0 Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Apparently fixed ?
Sincerly.
Hi Brecht,
If you not want associate LLVM to "package" Winlibs, can you explain how an "lambda" user can "unzip" standard package Winlibs and after install LLVM with it's own standard libraries as its distributed on mstorsjo/llvm-mingw/releases to refind same structure of directories like previous versions of "full" package Winlibs 32 bit or 64 bit with GCC 14.2.0 ?
Thank you for all.
Thierry.
PS : my need is only to test generation of same source code written in C/C++, either with GCC or either with CLANG.
LLVM 21.1.0 was released yesterday. Maybe the bug that was preventing it from compiling from GCC is now gone?
@brechtsanders You have a recent Clang in your GCC 14.2.0 series. You can always use this Clang to build the latest LLVM.
My goal is to build native GCC.
Along the way - on user request - LLVM was added, but keeping it GCC compatible by using GCC's standard libraries so GCC and LLVM could be mixed within one build environment. But I'm not sure that's such a good idea.
Better would be to have a separate LLVM build environment, with all the native LLVM standard libraries.
But as there already a good LLVM for native Windows available at https://github.com/mstorsjo/llvm-mingw/releases I don't see the point of dedicating my time to that at this point.
Having said that, I have already tried building packages with mstorsjo's LLVM, and it seems some still fail because LLVM doesn't have all the options yet that GCC+binutils have (for example when it comes to Windows resource files).
Sure ? llvm-windres.exe seems "do the job", not ? Yes, syntax accepted with these tool differ from this of original "windres" provided by GCC, but adaptation is possible.
Regards.
For example @<file> (to read options from file) is not supported by llvm-windres. That breaks builds of certain packages with LLVM.
I finalize my "proper" experience to install package CLANG/MINGW from [mstorsjo/llvm-mingw/releases](https://github.com/mstorsjo/llvm-mingw/releases last version llvm-mingw-20250910 with LLVM 21.1.1 and package WinLibs last version winlibs-x86_64-posix-seh-gcc-15.2.0-mingw-w64ucrt-13.0.0-r1.7z / winlibs-i686-posix-dwarf-gcc-15.2.0-mingw-w64ucrt-13.0.0-r1.7z (GCC last version 15.2.0) to respect 32 bit toolchain under C:\mingw32 and 64 bit toolchain under C:\mingw64., like precedent packaging of Winlibs in version by example GCC 14.2.0
Not simply !!!
Fisrt by downloading (beware to choose ucrt) these two packages : llvm-mingw-20250910-ucrt-i686.zip and llvm-mingw-20250910-ucrt-x86_64.zip And decompress it respectively to C:\mingw32 and C:\mingw64. After, decompress winlibs-i686-posix-dwarf-gcc-15.2.0-mingw-w64ucrt-13.0.0-r1.7z and winlibs-x86_64-posix-seh-gcc-15.2.0-mingw-w64ucrt-13.0.0-r1.7z to populate C:\mingw32 and C:\mingw64 again.
This order is mandatory because package CLANG provide tools with "same name" of MinGW/GCC but with behaviour different.
Big problem with toolchain 32 bit and CLANG compiler (and not with 64 bit toolchain !) : clang ld.lld: error: undefined symbol: ___chkstk_ms (and another errors too about "relocation" ...) I add "-v" to examine this problem during linkage, and then error appear after call of library libmingw32.a
Here, my first conclusion : file C:\mingw32\i686-w64-mingw32\lib\libmingw32.a is wrong after these two unzip/7zip, restore it from original llvm-mingw-20250910-ucrt-i686.zip, and all remain OK with CLANG compiler 32 bit, but I test also with GCC compiler ... with success.
Perhaps, it's not the "idoine" method to recover same toolchains like with Winlibs GCC 14.2.0 (with LLVM/CLANG),but it work.
Regards.
Just to inform, same behaviour with "recent" kits of llvm-mingw 32 bit when you mixed "at hand" Winlibs + mstorsjo/llvm-mingw/releases - llvm-mingw-20251021-ucrt-x86_64.zip - llvm-mingw-20251021-ucrt-i686.zip After many extract and, at the end, restore C:\mingw32\i686-w64-mingw32\lib\libmingw32.a from llvm-mingw-20251021-ucrt-i686.zip, I can use with "same packaged environment" GCC or CLANG ...
Regards.
I just think mixing the GCC and LLVM is a really bad idea, that's why for now I have stopped distributing the combined package.
One of the dangers for example will be when you mix stuff compiled with the different toolchains and their different standard libraries. There's not telling what will happen if you call free() from one standard library on memory allocated with malloc() from the other standard library.
The only way I can distribute a stable GCC build is exactly because I build it from the ground up (i.e. all dependencies and their dependencies, etc...) with the same toolchain.
Okay, you're rigth. Mixed toolchain is not "good idea". But, with your precedent mixed version (GCC 14.2.0 + LLVM 19.1.7), it's really simply to install these "mixed" toolchain ... It's only an opinion of "end user" not of expert it ...
Just to discuss ... , today, I discover that TDM-GCC-32 (very old version 10.3.0 !) don't work with getting "true" OS Version on Win32 systems (W11 24H2/25H2, with load "NTdll.dll" and after "GetProcAddress of "RtlGetVersion" entry into this DLL, the ONLY way to retrieve good version of OS) because many "include" files are lacking ... (like "winternl.h" by example).
But, with TDM-GCC-64, all work, and I can generate 32 bit version of this test also with option "-m32" and use of 32 bit libraries ... that'all ... 👍
Definitively, I prefer your version packaged of MinGW/GCC (very recent) in Winlibs 👍
Thank for your work.
Regards.
Hi,
Since few weeks, I discover that VS2022 ("Community" edition, installed on W11 64 bit 24H2/25H2 Family edition) provide these "mixed" toolchains. It offer both MSVC compiler environment but also CLANG compiler environment.
For MSVC, access to binary directory of MSVC is repectively to 32 bit or 64 bit ("cl" syntax) : - C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\Hostx86\x86 - C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64 For CLANG, access to binary directory is repectively to 32 bit or 64 bit ("clang" syntax, not recent version 19.1.7 ...) : - C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\bin - C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin
WARNING : In previous binary directories indicated to MSVC, number "14.44.35207" can change with (many) update by tool "Visual Studio Installer".
And also, MSYS2 64 bit offer this possibility to "mix" toolchains with MinGW/GCC and MinGW/CLANG with "same" binary directories : - C:\msys64\mingw32\bin -> presence of GCC and CLANG toolchains (32 bit) - C:\msys64\mingw64\bin -> presence of GCC and CLANG toolchains (64 bit)
Just for information about your choice to separate these toolchains into Winlibs since few months.
Regards.
Hi,
I remix yesterday Winlibs (GCC 15.2.0, MinGW32/64, ucrt, r3) with last package of LLVM-MingW [mstorsjo/llvm-mingw/releases](https://github.com/mstorsjo/llvm-mingw/releases, version LLVM 21.1.6). Same behaviour about "libmingw32.a" ... 32 bit. But, with precedent explication, all remain in order with these two toolchains.
Regards.
I still think it's a bad idea mixing these as they use different standard libraries.
That may lead to unstabilities and crashes.