Thanks! I ll see if i can build an installer and post a patch for build_llvm_release.bat.
Maybe makes sense to do it after flang-new ā flang refactor.
Testing for LLVM 19.1.1 on Linux PPC64LE is now complete. I did not find any regressions.
6578a0828ac6e041976635f4592f1bac4568b673 clang+llvm-19.1.1-powerpc64le-linux-rhel-8.8.tar.xz
The binaries can be found at Release LLVM 19.1.1 Ā· IBM/llvm-project Ā· GitHub.
19.1.1 x86/x64 Windows binaries are ready. Links and sha256 hashes below.
As discussed in the previous thread , Iāve also added these to the github release page .
LLVM-19.1.1-win32.exe
afa2c594f74f9fd3a93db1e0fe7c9c92a76486482cf26458d0d36ab0d48453fd
LLVM-19.1.1-win64.exe
95f03b6a8a0049e29898b0fadf84a0ea252f2e7f1b36db15a81aae11e912f675
clang+llvm-19.1.1-x86_64-pc-windows-msvc.tar.xz
621fc299fceb1bbdae927e355d1073034c9a1bbdda5a46a27e217c56af72f72a
Will we have LLVM-19.1.1-Windows-X64.tar.xz binaries available with all llvm targets built in clang & llc? Just like for 19.1.0 release?
Iām not sure I see point of clang+llvm-*-x86_64-pc-windows-msvc.tar.xz archive when LLVM-*-Windows-X64.tar.xz is much better, as that provides all targets, including commonly used wasm.
@mmozeiko The Windows binaries have been uploaded to the release page now.
1 Like
LLVM 19.1.1 Arm/AArch64 Linux and Windows on Arm binaries have been built and uploaded to
https://snapshots.linaro.org/llvm-toolchain/19/19.1.1/
ā sha256sum LLVM-19.1.1-woa64.exe
f256585b8e39cf95ce3191eb4002e269a755217f8492b240653c94c0ae077c8a
ā sha256sum clang+llvm-19.1.1-armv7a-linux-gnueabihf.tar.gz
bd1576bfed2f157f0ebc7033c8ee22467292ebad0c43b7fd69935d874cb2d43f
ā sha256sum clang+llvm-19.1.1-aarch64-linux-gnu.tar.xz
0549217747dab74103ec3e14cae1bbe09e3a070d0f6c1905b4c8c45d94d7c8cf
No regression since 19.1.0.
Iāve completed release testing for LLVM 19.1.1 on AIX 7.2. No regressions were found.
275352f71e6b057e49f23bb078fb91c27c7d8f67 clang+llvm-19.1.1-powerpc64-ibm-aix-7.2.tar.xz
The binaries are found here: Release LLVM 19.1.1 Ā· IBM/llvm-project Ā· GitHub
LLVM-*-Windows-X64.tar.xz is created by a github action (.github/workflows/release-binaries.yml), which I think is new for the 19 release.
clang+llvm-*-x86_64-pc-windows-msvc.tar.xz is created by llvm/utils/release/build_llvm_release.bat which is what weāve been using to build the official Windows release binaries so far. That also builds the installers (LLVM-19.1.1-win{32,64}.exe).
The situation is a bit confusing for everyone.
One concrete benefit of using the āoriginal binariesā is that theyāre built with PGO, rpmalloc, etc. so the toolchain is much faster. That script is also a bit stricter about ensuring that (most) tests pass before creating the binaries.
We reduced the number of included targets due to limitations of the NSIS installer framework. I thought people normally used Emscripten for Wasm, but if itās widely useful we can add it back.
Didnāt you evaluate an alternative to NSIS? What was the problem with that? Since even if we disable targets we are most likely going to hit that limit again soon.
Yes, that discussion was in Windows release packaging for 19.1.0-rc2 fails with `Internal compiler error #12345: error mmapping datablock to 5517122.` Ā· Issue #101994 Ā· llvm/llvm-project Ā· GitHub
We tried āNSISBIā instead of regular NSIS, but apparently that produced an installer not compatible with 7zip, which some users rely on.
Maybe when we hit the limit again weāll have to switch anyway, but we donāt know if that will be the next release or in a couple of years.
Thank you for keeping that in mind!
I find this acceptable, as long as we also provide a proper archive with Windows binaries alongside 7-zip-incompatible installer.
I am not trying to minimize this workflow - but to me it seems a bit backwards? Why not offer a installer that can be used as a installer and for the users that needs to unpack stuff with 7zip can dowload a .zip/tar.xz or something like that.
Based on @mstorsjoās previous comment at LLVM 19.1.0-rc2 tagged - #7 by mstorsjo, maybe this limit can be fixed by Meta issue to track changes for adding plugin and LLVM_BUILD_LLVM_DYLIB support for Windows Ā· Issue #109483 Ā· llvm/llvm-project (github.com)
I donāt think BUILD_LLVM_DYLIB is an acceptable performance trade-off.
Maybe thatās what weāll end up having to do eventually, but so far the installer has served both purposes, which is convenient.
This is a tangent in this context - but Iām not aware of BUILD_LLVM_DYLIB affecting performance of the built binaries significantly; I would be interested in seeing numbers to the contrary if thatās the case. Sure, dynamic relocations may eat up a little startup time, but I would think that itās negligible in the context of compiling things. (BUILD_SHARED_LIBS with many many sub libraries probably would have a different effect - but nobodyās proposing distributing that.) And itās an absolutely massive saver wrt file size. The main issue here of course is that itās not possible to use in an MSVC style build yet.
LLVM Embedded Toolchain for Arm binaries based on LLVM 19.1.1 can be found here:
Testing for LLVM 19.1.2 on Linux PPC64LE is now complete. I did not find any regressions.
7bf705d3746e407c211a2938285ebcabdd27e49e clang+llvm-19.1.2-powerpc64le-linux-rhel-8.8.tar.xz
The binaries can be found at Release LLVM 19.1.2 Ā· IBM/llvm-project Ā· GitHub.
1 Like
19.1.2 Intel Windows binaries are ready. Iāve signed and uploaded them to Release LLVM 19.1.2 Ā· llvm/llvm-project Ā· GitHub
1 Like