Including an older glibc in stdenv

Hello all,

I need to build some binaries, in nix, using an older glibc version (glibc 2.17). The approach I’ve taken is to create a local copy of the nixpkgs repo, and (at least, to get me off the ground) to replace the default glibc with glibc 2.17.

After some patching and trial and error, I’ve got things to the stage where I can do nix build .#glibc (I’m in the directory of my local nixpkgs) and see that glibc 2.17 is being built, and, therefore, the default stdenv uses glibc 2.17.

This unfortunately doesn’t fully solve my problem, because it seems that some of the utilities I need are still being built with glibc 2.27 - for example, if I try to build a test package using this stdenv, I am told:

/nix/store/d18ll2slr04w93pkzhn96748ssadldmj-binutils-patchelfed-ld-2.39/bin/ld: /nix/store/iqbzava2rqy6m0lq1j2mld74ll49j52b-glibc-2.17-224/lib/ version `GLIBC_2.27' not found (required by /nix/store/d18ll2slr04w93pkzhn96748ssadldmj-binutils-patchelfed-ld-2.39/bin/ld)

If I look at the bootstrap process that stdenv uses - in pkgs/stdenv/linux/default.nix of the current nixpkgs - it uses a tarball to kick off the build process:

bootstrapTools = import <nix/fetchurl.nix> {
  url = "";
  sha256 = "a5ce9c155ed09397614646c9717fc7cd94b1023d7b76b618d409e4fefd6e9d39";

and this tarball contains glibc 2.27, amongst other related files:


So I assume that this glibc is being injected early into the bootstrap process, and that some tools that are required for the bootstrap process - automake, patchelf etc - are built against this glibc, rather than my glibc 2.17, which gets inserted later into the bootstrap process.

Would anyone have a rough idea what might be the best way to work around this? It seems to me that I could:

  • replace the libc-related binaries in the bootstrap-tools tarball with binaries built from glibc 2.17, or
  • attempt to tweak the bootstrap process so that my glibc 2.17 gets used earlier on, or
  • attempt to rebuild the affected tools (patchelf and whatever else) with glibc 2.17 further downstream
    or some mysterious fourth thing I’ve not considered.

Thanks in advance, and also after the event


Stupid question: how much work would it be to fork 2.17-era Nixpkgs and add whatever you need there?

(You can install stuff from multiple checkouts from Nixpkgs into the same profile, if necessary)

Not a stupid question, that was the first thing I tried. But nixpkgs from that era is lacking a lot of modern syntax (ie, overlays and overrideAttrs), as well as a modern GCC , so it turned out not to be practical.

1 Like

Hmm, and if you try to port just the bootstrap tools and glibc from there?

(I just hope the glibc you need and the gcc you need will play nicely together, which is also not 100% obvious…)

if you are going to replace the bootstrap glibc with a very old version you will encounter compile errors. You probably want to rebuild the relevant tools against that older glibc version but they are probably not 100% isolated and dirty references will happen which could be hard to cleanup.