Hi.
I'm trying to compile a specific version of nightly, but with debug traces.
However, the generated libs have a different hash in their name, so I wonder what I'm doing wrong.
I did:
I checked out this hash in the rust repository and did ./x.py build. Since I had build other stuff before, I tried again after doing ./x.py clean, but same result.
I also tried with another commit to see if it was the wrong one and it was a strange behavior: the build libs (librustc_driver_….so and such in the stage2/lib` directory) had the same name. I was expecting them to have a different hash in their name since it was a different commit of rustc.
Is there any documentation about what change the hash in the library names?
Any idea what I'm doing wrong?
It takes so long to build a stage2 compiler that I'd like a way to know whether I'm compiling the right thing before I compile it. Any way to check this?
For the main part, you shouldn't ever actually need to compile a stage2 compiler. The stages work roughly like this:
stage0: compile HEAD with current beta
(this is #[cfg(bootstrap)])
stage1: compile HEAD with stage0 compiler
(this is #[cfg(not(bootstrap))])
stage2: compile HEAD with stage1 compiler
(this should be bit-for-bit equivalent to the stage1 compiler (modulo any remaining reproducible build issues))
So stage1 and stage2 are functionally equivalent compilers.
Additionally, if you aren't doing so already, --keep-stage 0 will allow you to keep the compiled stage0 artifacts and just rebuild stage1 with any changes you've made to the config. (The same for --keep-stage 1 when building stage2.)
The library names are different in stage1 and stage2, so yeah that doesn't help.
Also, stage1 is the longer to compile, but I'll do keep-stage0 in the future.
Thanks anyway.
Wait.. are you suggesting that you’re going to compile rustc thrice? At least that’s what your comment sounds like to me.
As far as I remember, the default behavior of x.py (without any arguments) is to first compile both the new standard library and then the so-called stage0 compiler-artifacts using beta. The artifacts are then assembled (whatever that means, probably linked) to form the stage1 compiler. Then the stage1 compiler compiles the standard library library again and the so-called stage1 compiler artifacts which get assembled into the stage2 compiler. Finally one might think that the stage2 compiler would need to compile the standard library a third time because the stdlib is needed for compiling other rust programs that depend on it, but since this re-compilation of the standard library would be bit-for-bit equivalent to the stdlib that stage1 produced, that one is just copied instead. The last step is to use the stage2 compiler to build tools (I don’t remember which ones are included by default).
TLDR: If I recall correctly, you don’t ever re-produce bit-for-bit equivalent stuff in the bootstrapping.
I’m also not sure about the --keep-stage part. As far as I remember, keep-stage 1 is what you need to speed up re-compilation of the stage1 compiler because it doesn’t recompile the standard-library with the stage1 compiler, and --keep-stage 0 is something I never heard of, so no idea what its use case is.
I don't think that doing ./x.py build builds it three times. The stage2 is very fast, compared to the rest. I just need the libraries built in the stage2.
The default build just copies the stage1 compiler to stage2 on the assumption that they should be identical. There's a configuration option for full-bootstrap if you want to do it all.
Maybe I didn't explained correctly what I want.
I'm trying to build nightly-2020-05-25 locally.
This nightly contains a lib called librustc_driver-fefef43299f39010.so. There seems to be a hash or something in its name: fefef43299f39010 and this changes for other version of rustc. For example, nightly-2020-05-09 has the lib librustc_driver-1772d117996df5b4.so.
Now, I wonder what makes this hash (or whatever this value is) change because when I try building the commit 46e85b432 (which should correspond to nightly-2020-05-25 from my understanding) of rustc locally, I get a different name for this library.
My end goal being to be able to compile the nightly-2020-05-25 and get the exact same files.
The hashes in the filenames often won't be identical to the hashes that appear in the release distribution. There are many settings that influence the hash (like the enabled features, etc.). It might be possible to get the exact same hash by building via Docker the same way the distribution is made (for example, src/ci/docker/run.sh dist-x86_64-linux), but even that I'm not sure will be the same (and using the docker image as-is might be a bit awkward).