Add Path to "failed to wrap ld.lld: failed to create unwrapped directory"

[C0D3-M4513R]

Problem you are trying to solve

I want to check, why the error message below happens.
For that I'd like to investigate what's at the path, so I can potentially remove the offending file.

Error Message:

info: installing component 'rustc'
 70.2 MiB /  70.2 MiB (100 %)  13.4 MiB/s in  5s ETA:  0s
warning: failed to wrap `ld.lld`: failed to create unwrapped directory

Caused by:
    File exists (os error 17)

Stack backtrace:
   0: <rustup::dist::component::package::DirectoryPackage as rustup::dist::component::package::Package>::install
   1: <rustup::dist::component::package::TarGzPackage as rustup::dist::component::package::Package>::install
   2: rustup::dist::manifestation::Manifestation::update
   3: rustup::dist::dist::try_update_from_dist_
   4: rustup::install::InstallMethod::install
   5: rustup::toolchain::distributable::DistributableToolchain::update_extra
   6: rustup::cli::rustup_mode::update
   7: rustup::cli::rustup_mode::main
   8: rustup_init::main
   9: std::sys::backtrace::__rust_begin_short_backtrace
  10: main
  11: __libc_start_call_main
  12: __libc_start_main_alias_2
  13: _start
info: installing component 'rustfmt'

Solution you'd like

The offending path, that already exists should be displayed for the user to see, so that capable users can do something about the error.

Notes

This is happening on a NixOs install. It is quite possible, that this error is caused by some leftover symlink by home-manager.

[djc]

Looking at <DirectoryPackage as Package>::install(), it's not completely obvious where this is coming from: we call utils::read_file() but it should yield an error that is contextualized with the file name (both on 1.27 and on master). The other filesystem operations are executed as part of a transaction which I think would have resulted in extra stack frames on this backtrace?

[0xangelo]

I see the same error (although not with a backtrace like you, maybe I don't have the env var set up). I'm also on a NixOS install of rustup

[rami3l]

Looking at <DirectoryPackage as Package>::install(), it's not completely obvious where this is coming from: we call utils::read_file() but it should yield an error that is contextualized with the file name (both on 1.27 and on master). The other filesystem operations are executed as part of a transaction which I think would have resulted in extra stack frames on this backtrace?

@djc I'm pretty sure this is something like ~/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin/gcc-ld/ld.lld.

[rami3l]

@djc This error message does NOT come from our code, so I don't think we should take responsibility:

https://github.com/NixOS/nixpkgs/blob/2e1715cf7cf3c1e79436d566962aeedaffbfb49d/pkgs/development/tools/rust/rustup/0001-dynamically-patchelf-binaries.patch#L26

For all NixOS users above, my guess would be that, for the moment being, you might have better chance running the original rustup with programs.nix-ld.enable = true;.

[C0D3-M4513R]

In my case it did end up being just being some stuck directory that had to be removed.
After removing a directory (I don't remember which), and rerunning the rustup upgrade command everything worked.

I guess I will refile this bug on nixos, when I next occurr it.