Bump flake and fix wasm builds; CI improvements

[steveej]

please see commit messages for details

[jost-s]

@steveej It looks fine to me but the tests are failing.

[steveej]

@steveej It looks fine to me but the tests are failing.

yes it's not fine yet. the workaround clears the env of something that's apparently needed. i couldn't figure out yet what needs to be removed from the env and stop inheritance for the Command. that'd be preferable IMO

[steveej]

cleanup

[steveej]

@jost-s i figured out the env var that needs to be cleared. if you approve i'll clean up the commit history before merging.

[jost-s]

@steveej Wait, this seems like a problem with the rustDev shell. Instead of working around it here, should it not be removed there?

[jost-s]

I'll merge this as a workaround to unblock the release.

[steveej]

@jost-s

@steveej Wait, this seems like a problem with the rustDev shell. Instead of working around it here, should it not be removed there?

the inner cargo build --target wasm32-unknown-unknown spawned from the build.rs runs in the context of the outer cargo build [--target x86_64-linux-unknown-gnu] (i augmented the target architecture spec which is implied by the ubuntu-latest CI runner).

for that target, the rustDev shell sets these flags: export CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS="$CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS -Clink-arg=-fuse-ld=mold".

the effect of it is the environment variable that i removed from the inner job in this PR, because we don't intend that effect for the wasm target.

let me know if that explains it for you.

[jost-s]

@steveej In effect does that mean that mold cannot link wasm targets? And why is that outer env var's target x86_64 even applied for wasm32?

[steveej]

In effect does that mean that mold cannot link wasm targets?

true.

And why is that outer env var's target x86_64 even applied for wasm32?

because of this, specifically the bold part

the inner cargo build --target wasm32-unknown-unknown spawned from the build.rs runs in the context of the outer cargo build [--target x86_64-linux-unknown-gnu] (i augmented the target architecture spec which is implied by the ubuntu-latest CI runner).

within that context, the environment variable CARGO_ENCODED_RUSTFLAGS=-Clink-arg=-fuse-ld=mold is set. spawning another cargo build inherits it from its parent process. hence this PR specifically removes this variable from the spawned process.

[jost-s]

@steveej But the target platforms are different, it's x86_64 in one and wasm32 in the other. Why a specific target triple if it's applied in a general way? Is the x86_64 applied anyway despite the difference in platform?

[steveej]

@jost-s

1. nix develop spawns a shell that will have CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS -Clink-arg=-fuse-ld=mold" set
2. cargo build [--target x86_64-linux-unknown-gnu] discovers CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=... in its environment and translates this to CARGO_ENCODED_RUSTFLAGS=... for itself and its spawned children.
3. while processing the test/build.rs, cargo build --target wasm32-unknown-unknown is spawned, which discovers CARGO_ENCODED_RUSTFLAGS=... in its environment and thus uses mold accordingly.

does that help?