Wasm build fails on mac arm with apple clang 17

[ntjohnson1]

Repro:

$ cargo --version
cargo 1.87.0 (99624be96 2025-05-06)
$ rustup --version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)
$ rustc --version
rustc 1.87.0 (17067e9ac 2025-05-09)
$ clang --version
clang --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix

$ cargo build --target wasm32-unknown-unknown --release
Compiling psm v0.1.26 (/Users/nick/repos/stacker/psm)
warning: psm@0.1.26: warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: /Users/nick/repos/stacker/target/wasm32-unknown-unknown/release/build/psm-ab2ede286de84622/out/libpsm_s.a the table of contents is empty (no object file members in the library define global symbols)
   Compiling stacker v0.1.21 (/Users/nick/repos/stacker)
error: failed to build archive at `/Users/nick/repos/stacker/target/wasm32-unknown-unknown/release/deps/libpsm-36af2f6cb1fcbb57.rlib`: LLVM error: section too large

This appears to be related to the note in wasm32.s about a relatively recent llvm but this is the base version on macos arm (M4 etc).
This appears to be impacting upstream crates who are coming up with various work arounds
https://github.com/drager/wasm-pack/issues/1381
apache/datafusion#13766

[nagisa]

Pull requests that fix this in non-intrusive way are welcome. I don't myself have access to apple clang so there's that.

[ntjohnson1]

Makes sense. I'm digging into it but wanted to create the issue here at potentially the root cause to report what I find.

It looks like there's some issue when creating the rlib archive from the cc crate that is corrupting things (those padding bytes are what cause the llvm section too large error if I inspect the result)

With llvm 17

$ cargo build --target wasm32-unknown-unknown --release
$ ls -la target/wasm32-unknown-unknown/release/build/psm-*/out/
   libpsm_s.a
$ ar -x target/wasm32-unknown-unknown/release/build/psm-*/out/libpsm_s.a
$ llvm-readobj --sections wasm32.o
   Barfs with section too large
$ llvm-readobj --sections psm/src/arch/wasm32.o
   Works
$ hexdump -C wasm32.o > extracted.hex && hexdump -C psm/src/arch/wasm32.o > original.hex && diff original.hex extracted.hex
25,26c25,26
< 00000180  3c 02 06 46 04                                    |<..F.|
< 00000185
---
> 00000180  3c 02 06 46 04 0a 0a 0a                           |<..F....|
> 00000188

When I do a similar exploration of the resulting libpsm.a I don't have these trailing bytes with a newer llvm.

[ntjohnson1]

Ok not yet ready for a non-intrusive PR but adding dummy bytes to the assembly resolves the corruption issue. I couldn't figure out how to make the mac ar avoid introducing this padding. Then to make the tests work with wasm32-unknown-unknown on mac I had to add a wasm runtime dev dependency for mac and add a config to use that in the test. Otherwise looks like it all works on my end. Hopefully should have time to tie this together a little nicer tomorrow.