Hi,
I am running Nix/Home-manager on Arch Linux and am trying to install the Eww package either through AUR or build from source. The problem is that the built binary is trying to link libraries under /nix/store:
# ldd eww | grep nix
libgcc_s.so.1 => /nix/store/c2yb135iv4maadia5f760b3xhbh6jh61-gcc-13.2.0-lib/lib/libgcc_s.so.1 (0x00007ee1a0e14000)
libm.so.6 => /nix/store/ddwyrxif62r8n6xclvskjyy6szdhvj60-glibc-2.39-5/lib/libm.so.6 (0x00007ee1a0350000)
libc.so.6 => /nix/store/ddwyrxif62r8n6xclvskjyy6szdhvj60-glibc-2.39-5/lib/libc.so.6 (0x00007ee1a0163000)
/nix/store/ddwyrxif62r8n6xclvskjyy6szdhvj60-glibc-2.39-5/lib/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000075781df31000)
Before the application can run properly on my system, I would have to manually override those libraries with patchelf
, something like:
sudo patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 eww
sudo patchelf --replace-needed libgcc_s.so.1 /lib/libgcc_s.so.1 eww
sudo patchelf --replace-needed libm.so.6 /lib/libm.so.6 eww
sudo patchelf --replace-needed libc.so.6 /lib/libc.so.6 eww
Since Eww is a Rust package, I’ve checked which Rust toolchain the system is pointed to by default:
# which rustc
/usr/bin/rustc
# which cargo
/usr/bin/cargo
Is there anything wrong with my Home Manager configurations? Thanks
I have found the culprit. When I was fiddling with LSPs and neovim, I put clang
under home.packages
, which also put ld
(and many other compiler-related applications not supposed to be there) under PATH. Moving them into programs.neovim.extraPackages
prevents such pollution.
2 Likes
Could you maybe clarify what you mean by “run properly”? Does launch? Does it show errors?
Generally the point of installing a package with nix is that it also includes the exact dependencies of what was specified in the package instead of linking against random things that just happen to be on the system.
The kernel in this case is an exception, which i find a bit weird. Do you per chance have some LD_*
paths specified?
1 Like
It launches without error after patching its interpreter and other library paths.
I don’t have LD_* environment variables defined in my shell.
All impacted LD paths are related to glibc and GCC directly, which makes sense to me if the wrong LD is picked from PATH during the compiling process. To verify this, I made a simple “hello world”-ish C file and built it with GCC. The wrong glibc is again picked up if the Nix LD executable is in PATH.
Ah, sorry, I misread the bit where you said you’re compiling from source yourself. Generally a good idea to not add compilers and libraries to your nix profile or home-manager to avoid that. I’d recommend making per-project configurations instead so you have dependencies as localized as possible.