Earlier, tdr reported that llvm-spirv couldn't find libLLVM on x86: ``` $ /usr/lib/llvm/19/bin/llvm-spirv /usr/lib/llvm/19/bin/llvm-spirv: error while loading shared libraries: libLLVM.so.19.1: cannot open shared object file: No such file or directory ``` This turns out to be because: ``` $ ldconfig ldconfig: Cannot mmap file /usr/lib/llvm/19/lib/libLLVM.so.19.1 ``` and.. ``` 2.9G Feb 22 08:22 /usr/lib/llvm/19/lib/libLLVM.so.19.1 ``` We could do with a QA check for libraries that become too large to be loadable on 32-bit systems. The glibc docs on mmap [0] say """ If the LFS interface is used the file size on 32-bit systems is not limited to 2GB (offsets are signed which reduces the addressable area of 4GB by half); the full 64-bit are available. """ so I guess we want to warn about 2GB in the non-LFS case, but I still wonder whether such a large library will end up causing problems anyway. [0] https://www.gnu.org/software/libc/manual/html_node/Memory_002dmapped-I_002fO.html
wrt libLLVM, rebuilding with: ``` LLVM_TARGETS="(WebAssembly) (X86) -AArch64* -AMDGPU* -ARC -ARM* -AVR* -BPF* -CSKY -DirectX -Hexagon* -Lanai* -LoongArch* -M68k -MSP430* -Mips* -NVPTX* -PowerPC* -RISCV* -SPIRV -Sparc* -SystemZ* -VE* -XCore* -Xtensa ``` led to a far more reasonable ``` -rwxr-xr-x 1 root root 51M Feb 22 17:17 /usr/lib/llvm/19/lib/libLLVM.so.19.1 ``` which also seems to imply that some targets are far larger than others (probably huge tables)? We should reconsider bug 767700 in that light.
