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
When I try to go deep, I found the stage1 rustc failed to find crate std:
$ LD_LIBRARY_PATH=$PWD/build/x86_64-unknown-linux-gnu/stage1/lib/x86_64-linux-gnu/ "$PWD/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" main.rs
error[E0463]: can't find crate for `std`
It may be a trivial issue. But I am too new to Rust. I will be responsive to provide additional information.
Which rust version did you install? And what
config.toml did you use to build?
Installing the latest Rust 1.68.2.
link-shared = true
targets = "X86"
# disable experimental targets, we certainly don't want them (only AVR at the moment)
experimental-targets = ""
build = "x86_64-unknown-linux-gnu"
host = ["x86_64-unknown-linux-gnu"]
target = ["x86_64-unknown-linux-gnu"]
cargo = "/usr/bin/cargo"
rustc = "/usr/bin/rustc"
docs = true
submodules = false
python = "/usr/bin/python3"
locked-deps = true
vendor = true
verbose = 2
extended = true
tools = ["cargo"]
prefix = "/usr"
sysconfdir = "/etc"
bindir = "/usr/bin"
libdir = "/usr/lib/x86_64-linux-gnu"
datadir = "/usr/share"
mandir = "/usr/share/man"
docdir = "/usr/share/doc/rust"
optimize = true
channel = "stable"
debuginfo-level = 2
debuginfo-level-std = 0
debuginfo-level-tools = 2
backtrace = true
rpath = false
default-linker = "/usr/bin/gcc"
cc = "/usr/bin/x86_64-unknown-linux-gnu-gcc"
cxx = "/usr/bin/x86_64-unknown-linux-gnu-g++"
linker = "/usr/bin/x86_64-unknown-linux-gnu-gcc"
ar = "/usr/bin/x86_64-unknown-linux-gnu-gcc-ar"
llvm-config = "/usr/bin/llvm-config"
I don't see anything obviously wrong. Try opening an issue at Issues · rust-lang/rust · GitHub.
I can reproduce this on my Fedora 36 host, just set
libdir = "/usr/lib/x86_64-linux-gnu".
And the issue appeared since Rust 1.67.0.
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
config.toml. Instead, they move the shared libraries to
/usr/lib/x86_64-linux-gnu manually and keep
/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.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.