Strip absolute local paths from binaries

[brson]

What problem does your feature solve?

For builds to be reproducible, the binaries cannot contain absolute filesystem paths. Today there are cases where rustc embeds absolute paths even when debuginfo is stripped.

Namely, panic messages emit paths via the builtin file! macro. In some cases these paths are relative (the local project, the prebuilt standard library); but in some they are absolute (crates.io dependencies, the standard library built from source).

So e.g. today the eth_abi example crate includes absolute paths for the soroban-sdk crate and the alloy-sol-types crate because it calls functions in these crates that in turn may panic.

Soroban probably doesn't care about these paths at all - I don't know if they make it all the way to soroban's own panic logging; and they increase wasm size.

What would you like to see?

Soroban-cli should invoke the compiler in a way that eliminates these absolute paths.

The main mechanism for doing this is the --remap-path-prefix flag to rustc.

There are more sophisticated mechanisms for controlling these paths in cargo via `trim-paths but they are unstable.

The linked trim-paths docs describe which paths cargo tells rustc to sanitize, and soroban-cli can do the same. The path to the local registry cache is the most important; the path to the local standard library also may be useful to remap.

The following patch to contract/build.rs is a working proof of concept for remapping the registry path:

+            {
+                assert!(std::env::var("RUSTFLAGS") == Err(std::env::VarError::NotPresent));
+                let cargo_home = home::cargo_home().map_err(Error::CargoHome)?;
+                let cargo_home = format!("{}", cargo_home.display());
+                let registry_prefix = format!("{cargo_home}/registry/src/");
+                let rustflags = format!("--remap-path-prefix={registry_prefix}=");
+                cmd.env("RUSTFLAGS", rustflags);
+            }

Unfortunately it seems like this must be done through the RUSTFLAGS variable, which adds some complications if the caller is also using it.

What alternatives are there?

Discussed above.

[brson]

I do intend to write a patch to fix this specific issue, which will improve reproducibility when built from different configurations of the same host platform.

It won't result in reproducible builds when built on different host platforms though because of host-specific data leaking into cargo's -C metadata generation. I've done some investigation into the issue here rust-lang/cargo#8140 (comment)

[HunterSides]

@brson This may be a long shot and I'm not entirely sure how you'd go about testing it on your end, but zig released https://github.com/rust-cross/cargo-zigbuild?tab=readme-ov-file as a drop in solution to rust cross compilation issues that I think may be relevant to the issues you're facing. And full disclaimer, I am by no means a rust developer, this is just pure anectdotal speculation on my end based on what I know about Zig

Here are a few links that I found interesting that may be of relevance as well.
https://docs.rs/cargo-zigbuild/latest/cargo_zigbuild/struct.Rustc.html
https://actually.fyi/posts/zig-makes-rust-cross-compilation-just-work/
https://ziglang.org/learn/overview/#cross-compiling-is-a-first-class-use-case

some other maybe useful links about Zig
https://www.quicknode.com/guides/cross-chain/layerzero/what-is-layerzero
https://youtu.be/5_oqWE9otaE?t=953 <--zig creator discussing cargo_zigbuild

[brson]

One thing to note here is that this affects the builtin file! macro, so if some dependency is doing something funky with that macro it could break in unexpected ways.