I have a nix expression for an FHS shell that looks like:
{ pkgs ? import <nixos> { } }:
let unstable = import <nixos-unstable> { };
in with pkgs;
(pkgs.buildFHSUserEnv {
name = "fhs";
targetPkgs = pkgs:
with pkgs; [
nodejs
which
curl
git
gnumake
gcc
cmake
unstable.neovim
python
unzip
hostname
file
];
}).env
And I get this error when trying to start the unstable neovim inside said nix-shell:
/nix/store/can473ld4dc8izcjlm4i5daxsh1yl5d8-bash-4.4-p23/bin/bash: /usr/lib/libc.so.6: version `GLIBC_2.33' not found (required by /nix/store/can473ld4dc8izcjlm4i5daxsh1yl5d8-bash-4.4-p23/bin/bash)
Is it not possible to mix channels in nix-shell?
your shell is bringing in binaries which are linked against a newer version of glibc.
You have two options:
- pull packages from a similar checkout of nixpkgs as your system
- update your system, then restart
Thanks Jon, I found another answer of yours to a similar question and have run nixos switch --upgrade
and rebooted, however that didn’t help. Forgive me if you meant something different by “update your system”.
Anyway, I’m more interested in understanding the cause of this issue.
I think I’ve found the issue: LD_LIBRARY_PATH
If I unset LD_LIBRARY_PATH
inside nix-shell, neovim works fine
The neovim derivation is exactly the same in- and outside the nix-shell, ldd
is the same version, but LD_LIBRARY_PATH
is set to /run/opengl-driver/lib:/run/opengl-driver-32/lib:/usr/lib:/usr/lib32
in nix-shell, where it is unset outside it
So where is that pesky LD_LIBRARY_PATH
coming from?
being a stable user, and pulling in packages from unstable would also have the same behavior
You can use LD_PRELOAD
, and set that to the newer glibc.so, and that should also fix your issues.
So where is that pesky LD_LIBRARY_PATH
coming from?
That’s probably from buildFHSUserEnv, as that allows for the libraries to be found.