Custom source standard library

[ehuss]

This issue is for tracking the possibility of using custom source for the standard library.

It should be acknowledged that this is unlikely to be on a path to be stabilized for the foreseeable future.

[crlf0710]

In my mind it would be better to just to enable the user to supply prebuilt-binary for every crate in the dependency graph using some Cargo.toml syntax.

This will solve this use case automatically. But it's worth a separate topic alone, and absolutely doesn't beyond to the MVP.

[plauche]

Is this feature still pretty far out on the road map? I was looking at transitioning away from xargo but the ability to build std from custom source is a must for me at the moment.

[Ericson2314]

So we want to fetch the source in a distro context, so rustup isn't appropriate. It's fine for us if it's quite unstable, but I would be nice if there was an escape hatch in Cargo.

CC @kloenk

[RalfJung]

Miri needs to do its own sysroot build, which it currently does via xargo -- but using -Zbuild-std would be nicer, of course.

However, this issue is one (not the only) blocker on that road: Miri currently supports the MIRI_LIB_SRC env var to configure where to get the sources for the sysroot build from, and that feature is useful often enough that I'd rather not lose it.

[Ericson2314]

https://github.com/kolloch/crate2nix/ is project I've given cross support and enough stuff to replicate -Z build-std with equivalent hacks. We an substitute custom stdlib sources in just fine.

My point in bringing this up is that it should be really easy to get this feature for free once the implementation isn't extremely rigid mixing mechanism and policy.

[est31]

cc also https://github.com/rust-lang/rust/issues/101691 which is about making it possible to just compile the standard library in rustc and then using rustup toolchain link.

[vadixidav]

In my case I am using msp430 and the linker provides builtins for the hardware multiplier. See https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/msp430/lib2hw_mul.S for relevant code. I want to submit a PR to compiler_builtins to remedy the situation, mostly by making it not generate duplicate symbols for this architecture, but it looks like I need to build the whole toolchain from scratch, which is a bit prohibitive. It would be really nice to be able to swap out the compiler_builtins.

[bjorn3]

If the project with which you want to test it only depends on libcore and not liballoc, I think you can use -Zbuild-std=core and then add the version of compiler_builtins you want to test as regular dependency to Cargo.toml and maybe add a use compiler_builtins;.

[vadixidav]

If the project with which you want to test it only depends on libcore and not liballoc, I think you can use -Zbuild-std=core and then add the version of compiler_builtins you want to test as regular dependency to Cargo.toml and maybe add a use compiler_builtins;.

I tried this, but it still complains about duplicate compiler_builtins rlib.

[evanrichter]

I believe I found a suitable, though unstable escape hatch

Set the __CARGO_TESTS_ONLY_SRC_ROOT environment variable when you do -Zbuild-std and cargo will use the specified path to the custom source

[TDecking]

`__CARGO_TESTS_ONLY_SRC_ROOT´ unfortunatly does not work. It allows for building, but not for linking.

[evanrichter]

hmm, that might be correct for dynamic linking, I haven't verified. but it certainly works with RUSTFLAGS="-C target-feature=+crt-static" and musl targets

[TDecking]

So, I've managed do diagnose my case.

In my case, I only made changes to core, and I passed -Z build-std=core as additional flags. However, my program used std, which was not specified as a component. Which meant that the original standard library was linked. Passing -Z build-std=std,core instead fixed things.

This is likely going to trip up a lot more users.

[dullbananas]

Here's a workaround for experimenting with changes to std

• To set up, run:

  cp --recursive ~/.rustup/toolchains/nightly-* new-directory-path
  rustup toolchain link new-toolchain-name new-directory-path

• Make changes in new-directory-path/lib/rustlib/src/rust/library/std
• Use cargo +new-toolchain-name with -Z build-std to build a crate using the modified standard library
• When the standard library is modified again, the changes will not take effect until you remove the artifacts from the target directory in your crate. To do this when using release mode, run:

  rm -rf target/*/release/build/std-*