Skip to content

Bundled LLD is not found when sysroot is changed #48772

Closed

Description

@phil-opp

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.

Activity

  1. alexcrichton commented on Mar 6, 2018

    @alexcrichton
    Member

    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

  2. changed the title [-]Bundled LLD is not found on macOS[/-] [+]Bundled LLD is not found on for changed sysroots[/+] on Mar 6, 2018
  3. changed the title [-]Bundled LLD is not found on for changed sysroots[/-] [+]Bundled LLD is not found when sysroot is changed[/+] on Mar 6, 2018
  4. phil-opp commented on Mar 6, 2018

    @phil-opp
    ContributorAuthor

    @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).

  5. alexcrichton commented on Mar 6, 2018

    @alexcrichton
    Member

    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.
  6. added
    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
    C-bugCategory: This is a bug.
    on Mar 6, 2018
  7. japaric commented on Mar 7, 2018

    @japaric
    Contributor

    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).

  8. FenrirWolf commented on Mar 8, 2018

    @FenrirWolf
    Contributor

    I made a PR to xargo that seems to do the trick

  9. added a commit that references this issue on Mar 9, 2018
  10. steveklabnik commented on Mar 10, 2018

    @steveklabnik
    Contributor

    So, now that new xargo is released, should we close this?

  11. phil-opp commented on Apr 20, 2018

    @phil-opp
    ContributorAuthor

    The issue is resolved by the new xargo version, so I'm going to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions