./x.py doc fails when using a local_rebuild stage0

[cuviper]

When using the same version of rustc as stage0 in a new build -- a local_rebuild as rustbuild calls it -- building documentation fails with errors like this:

 Documenting std v0.0.0 (file:///builddir/build/BUILD/rustc-1.22.1-src/src/libstd)
/builddir/build/BUILD/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc: symbol lookup error: /builddir/build/BUILD/rustc-1.22.1-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc: undefined symbol: _ZN12rustc_driver15target_features17add_configuration17hf4e36c9e237094ebE

I figured out that this is at least somewhat the result of Build::force_use_stage1() for rustc, versus rustdoc being stage2 (built by stage1). This invocation ends up with LD_LIBRARY_PATH containing both "stage1/lib/" (built by stage0) and "stage1/lib/rustlib/$target/lib/" (built by stage1).

In the non-local_rebuild case, this works fine, because those two paths will have librustc_driver-HASH.so with different hash suffixes, as they were built by different versions of rustc.

With local_rebuild they get the same suffix, and since stage1/lib is first in the path, rustdoc is loaded with that. But the symbols within the libraries have different hash names, so the dynamic loader fails to find the exact ...add_configuration17hf4e36c9e237094ebE symbol.

I don't know if it's expected that their symbol names are different, even when the compiler version is the same. A workaround is to use --enable-full-bootstrap so force_use_stage1() returns false.

xref: https://bugzilla.redhat.com/show_bug.cgi?id=1533848

[cuviper]

I realized that reproducing this also depends on building without rpaths, because those preempt the LD_LIBRARY_PATH shenanigans.

Anyway, it looks like the switch to RUSTDOC_LIBDIR in #46592 has resolved this. The LD_LIBRARY_PATH when invoking rustdoc no longer has mixed origins.