Rust uses downloaded binaries for bootstrapping

[pmenzel]

At least for the Rust package versions with a build log file available, they seem to have been built with the binary Rust components from the version before.

@ellie:~$ grep static.rust-lang.org /amd/ellie/1/package/pkg/rustc-1.*-0/*log | grep rust-std
/amd/ellie/1/package/pkg/rustc-1.37.0-0/rustc-1.37.0-0.build.log:downloading https://static.rust-lang.org/dist/2019-07-04/rust-std-1.36.0-x86_64-unknown-linux-gnu.tar.gz
/amd/ellie/1/package/pkg/rustc-1.41.0-0/rustc-1.41.0-0.build.log:downloading https://static.rust-lang.org/dist/2019-12-19/rust-std-1.40.0-x86_64-unknown-linux-gnu.tar.xz
/amd/ellie/1/package/pkg/rustc-1.43.1-0/rustc-1.43.1-0.build.log:downloading https://static.rust-lang.org/dist/2020-03-12/rust-std-1.42.0-x86_64-unknown-linux-gnu.tar.xz
/amd/ellie/1/package/pkg/rustc-1.45.2-0/rustc-1.45.2-0.build.log:downloading https://static.rust-lang.org/dist/2020-06-04/rust-std-1.44.0-x86_64-unknown-linux-gnu.tar.xz
/amd/ellie/1/package/pkg/rustc-1.47.0-0/rustc-1.47.0-0.build.log:downloading https://static.rust-lang.org/dist/2020-08-27/rust-std-1.46.0-x86_64-unknown-linux-gnu.tar.xz
/amd/ellie/1/package/pkg/rustc-1.50.0-0/rustc-1.50.0-0.build.log:downloading https://static.rust-lang.org/dist/2020-12-31/rust-std-1.49.0-x86_64-unknown-linux-gnu.tar.xz
/amd/ellie/1/package/pkg/rustc-1.52.1-0/rustc-1.52.1-0.build.log:downloading https://static.rust-lang.org/dist/2021-03-25/rust-std-1.51.0-x86_64-unknown-linux-gnu.tar.xz
/amd/ellie/1/package/pkg/rustc-1.56.1-0/rustc-1.56.1-0.build.log:downloading https://static.rust-lang.org/dist/2021-09-09/rust-std-1.55.0-x86_64-unknown-linux-gnu.tar.xz

Upstream issue https://github.com/rust-lang/rust/issues/90555 has more details and references.

The to be rustc can be used in the configuration file, the question is if we just accept that there were downloaded binaries used in the chain.

[donald]

Good old bootstrapping problem.

There is a gcc rust compiler in development 1. Also there is mrustc, a rust compilter written in C++ 2. Anyway, as the rust language still evolves, these alternative rust compilers are probably not able to build the latest version of rust directly. In a rather old document 3, there was this chain: g++ -> mrustc@0.8.0 -> rust@1.19.0 -> rust@1.20.0 -> rust@1.21.0 -> rust@1.22.1 -> rust@1.23.0 -> rust@1.24.1 -> rust@1.25.0 -> rust@1.26.2 -> rust@1.27.2 -> rust@1.28.0 :-). Maybe mrustc can do a later version now, but then there are more versions to do on the other end.

There is a project, which claims to build rust 1.50 with mrustc 4.

But where did cc/c++ come from? I think, I once found a project,which starts with some small machine code expressed in hex (maybe 5 which uses 6 ?), but currently there is no good solution to the reproducible build bootstrap problem, although some people are working on it.

I don't think, we have the resources to develop one ourself. So for practical reasons I'd vote to pretend that we didn't see that.

[pmenzel]

@donald, do you have an idea, why the wrapper fails with the Rust build system as described in issue https://github.com/rust-lang/rust/issues/90562?

/usr/local/package/bin/rustc : rustc not found

Seems like from the our wrapper:

if [ -n "$PWRAP_rust" ]; then
  echo "$0 : $cmd not found" >&2;
  exit 1
fi

[donald]

Yes. The wrapper doesn't support recursion. So if, for example, /usr/local/package/bin/cargo invokes /usr/local/package/bin/rust, then the wrapper will die on purpose.

The idea of this check is to detect the case that the wrapper calls itself when you have a wrapper for a command which doesn't exist in the PATH set by the package.

Maybe we can make the environment variable a counter and allow a limited number of recursions.