You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bundled LLD is not found when sysroot is changed #48772
Since #48125, a LLD binary is shipped with Rust. According to this comment, it can be used by specifying "linker-flavor": "ld.lld" in target specs. However, this fails when the sysroot is changed, for example when compiling for a custom target using xargo. The following error occurs:
error: linker `lld` not found
|
= note: No such file or directory (os error 2)
The problem is that the lld binary is part of the host sysroot (e.g. in .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin on linux), so Rust does not find it when the sysroot is changed.
After some debugging with @steveklabnik I think this may be due to the use of xargo where the sysroot is changing so rustc's unable to find its original sysroot which contains lld
@alexcrichton Makes sense, thanks! I updated the issue title and description.
I wonder why lld is part of the sysroot in the first place. Is it target dependent somehow? Otherwise we could put it alongside the rustc and cargo executables, maybe as rust-lld (or alternatively in some subfolder not in PATH).
Ah yeah currently it is in the sysroot to mirror the placement of other items like codegen backends and gcc.exe on Windows. We don't want to place it alongside rustc/cargo as it would otherwise pollute PATH. Additionally we want to still maintain it as a bit of an internal dependency for now which may change (but placing it in PATH may make it much harder to change later).
One of two changes need to happen here I think:
Either xargo should be updated to symlink in the host target's directory into the custom sysroot it creates
Or rustc's own logic for adding items to PATH should always add the original sysroot, even if a custom one is specified.
Either xargo should be updated to symlink in the host target's directory into the custom sysroot it creates
We already do this in Xargo but we copy / hardlink / symlink only the lib directory, not the bin directory which is where lld is. I'd be happy to accept a PR that adds the bin directory to Xargo's copy of the host / original sysroot.
Or rustc's own logic for adding items to PATH should always add the original sysroot, even if a custom one is specified.
We'll probably have to do this if / when Xargo functionality gets added to Cargo since the last invocation will be rustc --target $T --sysroot $S and the plan I sketched in rust-lang/cargo#4959 is to not have a copy of the original sysroot in the target directory (we don't need the original sysroot when compiling build scripts, proc macros, compiler plugins, etc. for the host because we never pass --sysroot to rustc when compiling those).
Activity
alexcrichton commentedon Mar 6, 2018
After some debugging with @steveklabnik I think this may be due to the use of xargo where the sysroot is changing so rustc's unable to find its original sysroot which contains lld
[-]Bundled LLD is not found on macOS[/-][+]Bundled LLD is not found on for changed sysroots[/+][-]Bundled LLD is not found on for changed sysroots[/-][+]Bundled LLD is not found when sysroot is changed[/+]phil-opp commentedon Mar 6, 2018
@alexcrichton Makes sense, thanks! I updated the issue title and description.
I wonder why
lldis part of the sysroot in the first place. Is it target dependent somehow? Otherwise we could put it alongside therustcandcargoexecutables, maybe asrust-lld(or alternatively in some subfolder not inPATH).alexcrichton commentedon Mar 6, 2018
Ah yeah currently it is in the sysroot to mirror the placement of other items like codegen backends and
gcc.exeon Windows. We don't want to place it alongside rustc/cargo as it would otherwise pollutePATH. Additionally we want to still maintain it as a bit of an internal dependency for now which may change (but placing it inPATHmay make it much harder to change later).One of two changes need to happen here I think:
PATHshould always add the original sysroot, even if a custom one is specified.japaric commentedon Mar 7, 2018
We already do this in Xargo but we copy / hardlink / symlink only the lib directory, not the bin directory which is where lld is. I'd be happy to accept a PR that adds the bin directory to Xargo's copy of the host / original sysroot.
We'll probably have to do this if / when Xargo functionality gets added to Cargo since the last invocation will be
rustc --target $T --sysroot $Sand the plan I sketched in rust-lang/cargo#4959 is to not have a copy of the original sysroot in the target directory (we don't need the original sysroot when compiling build scripts, proc macros, compiler plugins, etc. for the host because we never pass--sysrootto rustc when compiling those).FenrirWolf commentedon Mar 8, 2018
I made a PR to xargo that seems to do the trick
Merge #200
steveklabnik commentedon Mar 10, 2018
So, now that new xargo is released, should we close this?
phil-opp commentedon Apr 20, 2018
The issue is resolved by the new
xargoversion, so I'm going to close this.