Work around too-large LLVM files #7
Comments
|
Hmm - that's unfortunate. Is Git LFS totally out of the question here? It seems to be a good solution for this use case. Not sure what that'd mean in terms of performance and pricing though. The free plan seems to be rather limited.
That sounds a bit painful, as logic will need to be updated in various places for compressing an decompressing it. And since there's basically two ways to update this repo locally (through a |
I'd rather avoid it, TBH.
Makes sense. So I looked for a different solution and thought I found something in UPX (which is available in MSYS2). It provides a way to compress However, it seems that it does not like the $ upx.exe --verbose libLLVM-16.dll
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2023
UPX 4.0.2 Markus Oberhumer, Laszlo Molnar & John Reiser Jan 30th 2023
File size Ratio Format Name
-------------------- ------ ----------- -----------
upx: libLLVM-16.dll: CantPackException: can't pack new-exe
Packed 0 files.The explanation seems to be here: upx/upx#650 (support for win64/arm64* is labeled as |
|
Yes, they confirmed it's not going to work without that support being added (even when using the Just had a quick look at their codebase, but that stuff goes far beyond my knowledge, so I'm afraid I can't be of much help here 😞 |
|
@dennisameling maybe |
GitHub does not allow pushes that include files larger than 100MB. But LLVM's `libLLVM-16.dll` blasts right through that limit. Ideally, we would use UPX (https://upx.github.io/) to compress this DLL file down to size, but UPX is still waiting for Windows/ARM64 support (see upx/upx#650). So let's do the next best thing and use `strip.exe` to cut it down to size. Sadly, we cannot use the already-available `strip.exe` to do the job because binutils _also_ is still waiting for Windows/ARM64 support. To add insult to injury, we cannot even use the already-installed `llvm-strip.exe` because it is a Windows/ARM64 executable and we're running the `sync` workflow on hosted runners (which does not include Windows/ARM64 ones, yet). So let's bite the apple and install the x86_64 flavor of `llvm-strip.exe` and use _that_. This addresses #7. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It does. Closing via 4e626dd and https://github.com/git-for-windows/git-sdk-arm64/actions/runs/4794555349. |
|
@dennisameling note: this is but a band aid. The |
I might have started work on a potential longer term solution at MSYS2 builds a pretty versatile |
I have managed to build an Upstream as is (downloaded and extracted |
|
And I've got it to package. The binary extracted from the package is 51853k |
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git ffor Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git ffor Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git ffor Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git ffor Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git for Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git for Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git for Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Msys2 builds pretty versatile Clang and LLVM packages with LLVM backends to cross compile for various target architectures. That comes at the cost of big binaries, that challenge how we manage the Git for Windows SDK[1]. But for Git for Windows we don't need all of this. We only need a Clang that can compile ARM64 binaries on ARM64. [1] git-for-windows/git-sdk-arm64#7 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Latest night's
syncfailed with one error and two warnings:Unfortunately, there is no way around the 100MB restriction (other than going the Git LFS route).
One possibility to address this that comes to my mind is to store a compressed
libLLVM-16.dll.gz(it compresses down to 34MB viagzip-1) and uncompress it via/etc/profile.d/<something>(and add the uncompressed file to.gitignore)./cc @dennisameling
The text was updated successfully, but these errors were encountered: