Rust wasm32-unknown-unknown backend

[uzytkownik]

Project description
A safe, concurrent, practical language for web

Metadata

• homepage URL: https://rustwasm.github.io/ https://www.rust-lang.org/
• source URL:
• license: mit, apache2 (copied from rustc package)
• platforms: "aarch64-linux" "armv5tel-linux" "armv6l-linux" "armv7a-linux" "armv7l-linux" "mipsel-linux" "i686-linux" "x86_64-linux" "powerpc64le-linux" "riscv32-linux" "riscv64-linux" "x86_64-darwin" "i686-darwin" "aarch64-darwin" "armv7a-darwin" (copied from rustc package)

[uzytkownik]

Currently it looks like if you want to use wasm backend (including via wasm-pack crate) you need to use rustup.

[doronbehar]

There's a wasm-pack package right?

[uzytkownik]

@doronbehar It's not sufficient:

$ nix-shell -p wasm-pack rustc cargo --command 'wasm-pack build --target web --out-name wasm'
[INFO]: Checking for the Wasm target...
Error: wasm32-unknown-unknown target not found in sysroot: "/nix/store/alpdmy515slaacnfnk42696ixrnfjr1s-rustc-1.41.0"

Used rustc from the following path: "/nix/store/alpdmy515slaacnfnk42696ixrnfjr1s-rustc-1.41.0/bin/rustc"
It looks like Rustup is not being used. For non-Rustup setups, the wasm32-unknown-unknown target needs to be installed manually. See https://rustwasm.github.io/wasm-pack/book/prerequisites/non-rustup-setups.html on how to do this.

[JJJollyjim]

As far as I know our current rustc derivation doesn't support compiling the buildroot for a different target (unless you recompile the whole compiler, possibly)

That is definitely something that I think should be fixed

[stephank]

Related: #70238

It looks like LLVM and the Rust compiler itself are already built with wasm support, it's just that we don't have a Rust libstd build in place.

I was playing around with this a little bit, and have this so far: master...stephank:feat-rust-wasm

That adds a rustPlatform.libstd function which takes a target string (crude) and creates a derivation for building libstd by itself. I also added a rustPackages.libstd-wasm32 with the idea that CI could pick this up.

Idea was (with some more work) to have a selection of prebuilt libstd targets available that could be added to the Rust platform somehow, plus the user could always add more libstd targets by building from source.

But experimenting with what I have so far, it's already raising some issues:

• I'm reusing the rustc build infra, but duplicating some code from rustc.nix. Not sure if we can do better at code sharing, or build libstd directly with buildRustPackage. (Another downside of using rustc build infra is that it's also rebuilding the bootstrap tool every time.)

• I don't know how to add additional libstd builds to the rustc sysroot. Skimming the code, rustc appears to be doing realpath relative lookup? That'd mean something like buildEnv can't work.

• What works is adding RUSTFLAGS="-L /nix/store/[...]-libstd-1.43.0/lib/rustlib/wasm32-unknown-unknown/lib. But we can't just add that to every build (using a rustc wrapper script for example), because that causes errors for non-wasm builds.

• In addition, Rust seems to override the linker for a lot of targets: https://github.com/rust-lang/rust/blob/1.43.0/src/librustc_target/spec/wasm32_base.rs#L115
  We could fix this by adding a rust-lld symlink to LLVM's lld in the rustc postInstall maybe? (Workaround is RUSTFLAGS="-C linker=/nix/store/[...]-lld-9.0.1/bin/lld")

• I have a wasm project that mixes C and Rust, which has in the past required matching Rust and Clang builds using the same LLVM base. This is because, apparently, LLVM adds additional linking sections to wasm intermediate files, but this extra data is unstable and changes between versions.

  I thought with Nix actually building from the same LLVM base, this'd work, but it appears that's not the case or I'm doing something wrong. (Symptom is that the symbols from my C libraries are simply ignored, and the wasm file ends up with a bunch of imports it can't resolve when loaded.)

[Rizary]

@stephank how do you use wasm-pack currently? I have an error where wasm-pack cannot find directory.

after running ldd $(type wasm-pack), I got the following error:

wasm-pack:
ldd: ./wasm-pack: $No such file or directory
is:
ldd: ./is: $No such file or directory

[stale]

I marked this as stale due to inactivity. → More info

[kevincox]

Anyone opposed to updating the title to "Rust wasm32-unknown-unknown backend" just to be a bit more specific?

[kevincox]

Also I have managed to get this working here: https://gitlab.com/kevincox/word-store/-/blob/dcfe5a8fca6de4d49cae016acc91948365087dac/default.nix

The core is:

import <nixpkgs> {
	overlays = [
		(self: super: {
			rustc = (super.rustc.override {
				stdenv = self.stdenv.override {
					targetPlatform = super.stdenv.targetPlatform // {
						parsed = {
							cpu = { name = "wasm32"; };
							vendor = {name = "unknown";};
							kernel = {name = "unknown";};
							abi = {name = "unknown";};
						};
					};
				};
			}).overrideAttrs (attrs: {
				configureFlags = attrs.configureFlags ++ ["--set=build.docs=false"];
			});
		})
	];
}

Note that the docs are failing to build on this target, IDK if that is a packaging bug or an upstream bug but just remove that bit to see the issue. It was something about a reference to a unix-only module failing to resolve because it (correctly) isn't available.

[bendlas]

Found a way to build lldap wasm frontend with a self-built rustc: https://gist.github.com/bendlas/b93a26df508cbe57f49901b417cc4af6

[pbsds]

Should a wasm32-unknown-unknown enabled rustc be a part of the cross-compile infra? related

[pbsds]

rustc-wasm32 is now available, as of #247773