✔ how to build wasm32 targets from source · general

Someone know how to get some wasm32 targets built from a rust source? I don't have rustup on OpenBSD.

I've built the latest beta of 1.79 on OpenBSD and cargo-component compiles, wasm-tools compiles, and wasmtime almost compiles. With a little help, it does. But now to run the wasmtime tests, I need a wasm32-unknown-unknown target built and to build with cargo-component, I need a wasm32-wasi target built. How do I do that from the rustc source? Do I build a custom config.toml and then run x.py?

Joel Dice (Jul 03 2024 at 14:16):

Not sure how useful it is, but this is what I did last time I built Rust from source for both wasm32-wasi and wasm32-unknown-unknown: https://github.com/dicej/wasi-sockets-tests?tab=readme-ov-file#building-and-running. In my case, I was building for MacOS/ARM64 and using a pre-built wasi-sdk. In your case, you'll want to change the host target triple and point to a wasi-sdk you've built from source, I assume.

Frank Rehwinkel (Jul 03 2024 at 14:58):

@Joel Dice Thanks. Downloading and then building the wasi-sdk. Comes with its own LLVM source so downloading is taking a while. My machine is on the slow side.

Joel Dice (Jul 03 2024 at 15:05):

Yeah, and Rust will also download and build LLVM by default IIRC, so the whole thing will take a while.

bjorn3 (Jul 03 2024 at 15:06):

Frank Rehwinkel (Jul 03 2024 at 15:33):

FYI. OpenBSD comes with a POSIX make but the GNU make port can be installed to get the wasi-sdk built. Then the build step for wasi-sdk becomes NINJA_FLAGS=-v gmake package.

Frank Rehwinkel (Jul 05 2024 at 12:34):

I'm curious how they fit into the rust toolchain? Are they used by the LLVM compiler? By anything else? I assume it is crucial they are built for the architecture, hardware and OS and LLVM version, where the llvm portion of rustc will be running.

On a platform like OpenBSD that is Tier 3, but is a little odd because their changing libraries and ABI mean cross compiling to OpenBSD isn't really a thing, and there are a few patches applied to the rustc source before calling x.py, and there is a distribution of rustc and cargo that is three versions old now (1.76.0), and rustc usually (or always?) require bootstrapping with the immediately previous version of the compiler, it gets complicated. There is a maintained shell script for building beta on OpenBSD, but I had to invoke it multiple times to get from 1.76 to 1.79. And the script patches build files and creates its own config.toml without using the configure script.

But the build shell script that builds the config.toml doesn't allow for additional targets like wasm32-unknown-unknown and wasm32-wasi to be built. So I'm still trying different incarnations of the script or from building from stable source, applying the same patches, and my own versions of a config.toml that are a combination of what was used to compile the beta on OpenBSD with what is created when running ./configure with arguments as shown in the wasi-sockets-tests instructions that @Joel Dice provided above.

I don't know if I should be able to reuse the source and build directories that created the latest rustc beta to build just the two wasm targets if I use a new config.toml and run x.py again or is it designed to only build all necessary targets at once. I think I tried building just the wasm targets before and ran into some stage0 config or json issue but I can try that again too after my current attempt at a combination build fails.

Frank Rehwinkel (Jul 05 2024 at 15:04):

Tried to run the wasmtime that did build for OpenBSD with a wasm file built on another system but it coredumped. Does this gdb report help figure it out? Does anyone know if the unit header should be 4 or 2?

Core was generated by `wasmtime'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.27.1...done.
Loaded symbols for /usr/lib/libpthread.so.27.1
Loaded symbols for /home/frank/forks/wasmtime/target/release/wasmtime
Symbols already loaded for /usr/lib/libpthread.so.27.1
Reading symbols from /usr/lib/libc++abi.so.7.0...done.
Loaded symbols for /usr/lib/libc++abi.so.7.0
Reading symbols from /usr/lib/libc.so.99.0...done.
Loaded symbols for /usr/lib/libc.so.99.0
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
#0  0x0000036d14356d4f in wasmtime::engine::Engine::new::h6fbe63f97c9d341e ()
   from /home/frank/forks/wasmtime/target/release/wasmtime

Frank Rehwinkel (Jul 05 2024 at 15:10):

Well, the Dwarf error may have been caused by my use of 'gdb' rather than 'egdb'.

Chris Fallin (Jul 05 2024 at 17:05):

Regarding the wasmtime crash, check out my PR from 2021 — there is an additional mmap flag needed for stacks at least

Chris Fallin (Jul 05 2024 at 17:06):

(No tips on toolchain unfortunately — tier 3 and lack of up to date compiler binaries was the main reason I gave up)

Frank Rehwinkel (Jul 07 2024 at 18:24):

Thanks @Chris Fallin . That PR was a big help. With the change to adding the STACK flag for mmap and disabling the pooling allocator feature, both explained in your PR, a new wasmtime was able to run the simple hello world wasm file without issue, both in release and debug versions. (The wasm file had to be built on a different architecture though.)

I think I'm going to put this effort to the side now. For the same reasons you gave three years ago.

Stream: general

Topic: ✔ how to build wasm32 targets from source

Frank Rehwinkel (Jul 03 2024 at 02:16):