Unify glibc for bash and python and ghc


I noticed that glibc version used by bash and python and ghc might get out of sync. I preload python as a shared library and it breaks shell commands.

I think I need to customize bash derivation to use it with newer glibc version.

I didn’t touch glibc anywhere in my default.nix

nixpkgs only uses one glibc at a time. If you’ve got different packages using different glibc’s, it’s probably because you’ve gotten them from different revisions of nixpkgs.


I prepared a simple demo project which demonstrates how easy to mix glibc versions. The script makes shell, imports stock python interpreter, preloads python library and launches sub shell. In my case ${pkgs.bash}/bin/bash works meanwhile default bash gets glibc conflict. For bash script it is not a big deal but some libraries spawn subprocesses and depend on system call. I think the best solution is to setup derivation for bash with custom glibc (stdenv) and use it for mkShell. Though I haven’t found an example.

Your example repo works for me. I just see hello world twice when I use nix-shell.

1 Like

Wow - nonreproducable nix build

$ nix-shell --version
$ nix-shell (Nix) 2.11.0

$ nix-shell --pure
hello world
bash: /nix/store/8xk4yl1r3n6kbyn05qhan7nbag7npymx-glibc-2.35-224/lib/libc.so.6: version `GLIBC_ABI_DT_RELR' not found (required by /nix/store/ibp4camsx1mlllwzh32yyqcq2r2xsy1a-glibc-2.37-8/lib/libm.so.6)

1 Like
$ nix-shell --version
nix-shell (Nix) 2.17.0

Even if I use nix 2.11.0 I still can’t reproduce this. Are you sure your nix store is healthy? nix-store --verify --check-contents

1 Like

Any chance your $PATH ends up ordered weirdly? Dumping env in general and sifting for anything weird might not be a bad idea. If my suspicions are correct, adding bash to packages would fix it.

This is a shellHook, not a nix build, which despite --pure does keep some things for usability reasons.

I believe there was some discussion around whether nix develop should start bash interactively like nix-shell because it’s more usable that way, which was ultimately rejected because otherwise exactly this can happen due to user .bashrcs. But I forgot the details of that issue, may even have been the exact opposite.