| Summary: | dev-lang/rust: Compiling with USE="wasm" fails | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Imred Gemu <3dsusernamedimred9001> |
| Component: | Current packages | Assignee: | Randy Barlow <randy> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | 3dsusernamedimred9001, a.v.volobuev, bertrand, chall0+gentoo, christian+bgo, gnu_andrew, kripton, lotgyero, matoro_gentoo, navi, rust, stijn+gentoo, stkn |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
The build output
The output of emerge --info '=dev-lang/rust-1.79.0::gentoo' wasm object file disassembled wasm object file |
||
Created attachment 902682 [details]
The output of emerge --info '=dev-lang/rust-1.79.0::gentoo'
Rust 1.80.1 is also affected and given the cause of the issue (see below) any later version. The build process dies attempting to add d88f3e7e3b331ca8-clzdi2.o to an AR archive, using GNU ar. Manually running a simplified version of the command yields the original error message: # ar cq foobar.a d88f3e7e3b331ca8-clzdi2.o ar: foobar.a: error reading d88f3e7e3b331ca8-clzdi2.o: invalid operation The object file in question is a wasm binary module: # file d88f3e7e3b331ca8-ucmpti2.o d88f3e7e3b331ca8-ucmpti2.o: WebAssembly (wasm) binary module version 0x1 (MVP) Both the latest stable binutils and 2.42-r1 and testing 2.43-r1 fail to handle the wasm object file. LLVM (18)'s llvm-ar on the other hand works fine: # llvm-ar cq foobar.a d88f3e7e3b331ca8-clzdi2.o # llvm-ar t foobar.a d88f3e7e3b331ca8-clzdi2.o Which means manually overriding the AR implementation can be used as a workaround: # AR="`which llvm-ar`" emerge -avq dev-lang/rust I've attached the original wasm object file and the disassembled WAT for reference. Created attachment 904867 [details]
wasm object file
Created attachment 904868 [details]
disassembled wasm object file
> Which means manually overriding the AR implementation can be used as a
> workaround:
> # AR="`which llvm-ar`" emerge -avq dev-lang/rust
Thanks for the detailed description. I can confirm that rust compiles fine with the proposed workaround
Is this a dupe of #936635? (In reply to Stijn Tintel from comment #6) > Is this a dupe of #936635? Yes it is, the original poster's build log shows the same error. I can also confirm the setting AR to LLVM's AR prevents this error and builds successfully with a range of other USE flag settings. I hit the same error and the workaround resolved it. It would be good to get this fixed in the ebuild or even upstream. |
Created attachment 902681 [details] The build output Compiling with wasm support enabled fails with the following error: /var/tmp/portage/dev-lang/rust-1.79.0/work/rustc-1.79.0-src/build/x86_64-unknown-linux-gnu/stage2-std/wasm32-unknown-unknown/release/build/compiler_builtins-ef2902352451a8ee/out/libcompiler-rt.a: error reading /var/tmp/portage/dev-lang/rust-1.79.0/work/rustc-1.79.0-src/build/x86_64-unknown-linux-gnu/stage2-std/wasm32-unknown-unknown/release/build/compiler_builtins-ef2902352451a8ee/out/8926cfe43f081305-clzdi2.o I've tried removing all other USE flags, all CFLAGS other than "-O2", and all CPU_FLAGS_X86 respected by this package. The attached build log is the result of this configuration. I will also attached the emerge --info, though this shows USE and CFLAGS associated with the existing rust install on my system without wasm support. Here is the USE flags configuration for the attached build log: [ebuild R ] dev-lang/rust-1.79.0 USE="wasm* (-big-endian) -clippy -debug -dist -doc (-llvm-libunwind) -lto (-miri) -nightly -parallel-compiler -profiler -rust-analyzer -rust-src -rustfmt (-system-bootstrap) (-system-llvm) -test -verify-sig" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="-sse2*" 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"