rustup isn't patching binaries in `$sysroot/libexec`.

[eddyb]

Describe the bug

RA (rust-analyzer, the Rust LSP, in my case used from VSCode) started erroring like this:

Failed to run proc-macro server from path
  /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/libexec/rust-analyzer-proc-macro-srv,
  error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

I believe that libexec binary was added to Rust nightlies by @fasterthanlime's recent PR:

• Sync rust-analyzer, add rust-analyzer-proc-macro-srv binary to Rustc component rust-lang/rust#99756

(I should've noticed this sooner, but I guess I hadn't updated everything involved yet?)

Steps To Reproduce

Steps to reproduce the behavior:

1. rustup update nightly
2. patchelf --print-interpreter $(rustc --print=sysroot)/{bin/rustc,libexec/rust-analyzer-proc-macro-srv}

Expected behavior

Binaries in bin and libexec should be patchelf'd the same way - however, what we get is:

$ patchelf --print-interpreter $(rustc --print=sysroot)/bin/rustc
/nix/store/f3qlm2873bxlhxns4lrmrinvbzn933pj-glibc-2.34-210/lib/ld-linux-x86-64.so.2
$ patchelf --print-interpreter $(rustc --print=sysroot)/libexec/rust-analyzer-proc-macro-srv
/lib64/ld-linux-x86-64.so.2

Additional context

I believe this is happening because the rustup auto-patchelf logic hardcodes bin/lib:

nixpkgs/pkgs/development/tools/rust/rustup/0001-dynamically-patchelf-binaries.patch

Lines 18 to 19 in aaa1c97

	+ let (is_bin, is_lib) = if let Some(p) = src_path.parent() {
	+ (p.ends_with("bin"), p.ends_with("lib"))

Presumably the p.ends_with("bin") there should be changed to p.ends_with("bin") || p.ends_with("libexec")?

Notify maintainers

@Mic92

Metadata

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.28, NixOS, 20.09pre-git (Nightingale), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.9.1`
 - channels(eddy): `"nixpkgs-22.11pre388097.9a17f325397"`
 - channels(root): `"nixos-20.09pre218613.ae6bdcc5358"`
 - nixpkgs: `/home/eddy/.nix-defexpr/channels/nixpkgs`

[eddyb]

This workaround seems okay for now:

patchelf --set-interpreter $(patchelf --print-interpreter $(rustc --print=sysroot)/bin/rustc) \
  $(rustc --print=sysroot)/libexec/rust-analyzer-proc-macro-srv

However, this reminds me that because of how the @dynamicLinker@/@libPath@ values get compiled into nixpkgs-provided rustup, and only passed to patchelf (but not recorded as a GC root inside the toolchain-specific dir, at all), there's fragility when doing system updates and GC-ing the old ld-linux being referenced etc. (we solved this for rust-lang/rust bootstrapping but this never got communicated to the nixpkgs rustup patch maintainers etc. - let me know if I should open an issue for that)

[Mic92]

I fixed it for now just by extending the conditional.
It would be also possible to create a custom gcroot to the rustup installation directory, even without calling nix-build: https://github.com/nix-community/nix-direnv/blob/b353b222c1624bc82fddbe7dc287a105354322c8/direnvrc#L123
but I leave this for another day as this requires more time than I want to spent now on this problem.

[eddyb]

to the rustup installation directory, even without calling nix-build

The nix-build part isn't relevant - that's just because that code runs outside of any Nix build, rustup already has the necessary symlink targets in the form of @dynamicLinker@/@libPath@.

However, the GC root can't be per-.rustup, it has to be per-toolchain/component, since the patchelf invocation effectively "snapshots" the value every time a toolchain/component is installed (and over time one could end up with several different generations, esp. if explicit-date nightlies are used).

The use of /nix/var/nix/gcroots is interesting, I'm still not sure when it's needed - my understanding was that having symlinks to a store path anywhere was enough, but I suppose I may have been confused.

but I leave this for another day as this requires more time than I want to spent now on this problem

Understandable, thanks for handling the libexec problem!