Hello, I am not (yet) a Rust programmer. I want to update Rust for Freedesktop SDK. But Rust failed to build. It seems std library is not found.
Freedesktop SDK is a Linux environment. I am testing on x86_64 with GCC 12 and LLVM updated to 16.
No internet access during build time. A binary Rust is installed with the standalone installer. And then use it to compile Rust from the source. The source code is fetched from Other Installation Methods - Rust Forge
I think improve `filesearch::get_or_default_sysroot` r=ozkanonur · rust-lang/rust@71a3a48 · GitHub assumes librustc_driver.so will be in $sysroot/lib, while in your case it would be in $sysroot/lib/x86_64-linux-gnu. It should probably use the CFG_LIBDIR_RELATIVE env var set during compilation of rustc. The relevant code existed before this commit but was previously only used for finding the location of codegen backends other than LLVM. As LLVM is the only backend available on stable this didn't cause any issues until this commit which reuses the same logic for finding the sysroot (which in your case is /usr but ends up getting calculated as /usr/lib) Please open an issue to track a fix.
I found a solution from Debian/Ubuntu. They don't set libdir to /usr/lib/x86_64-linux-gnu in config.toml. Instead, they move the shared libraries to /usr/lib/x86_64-linux-gnu manually and keep rustlib in /usr/lib/rustlib. A patch is applied to get this work after Rust 1.67.
That patch actually breaks what the commit in question was trying to support: Infering the default sysroot when linking an external tool against rustc_driver. In that case looking relative to the executable dir will not find the sysroot. The commit in question changed this to inferring based on the location of librustc_driver.so. The correct fix would be to take cfg!("CFG_LIBDIR_RELATIVE") into account to find the sysroot from the librustc_driver.so location.