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.

1 Like

@harris-chris Sorry to bother you half-a-year later, but did you have any success with this? I have exactly the same task, so i was hoping you could share your results :slight_smile:

Hello, I didn’t find a generalisable solution to this, but I did manage to set up a few build environments, using older gccs and glibcs. What version are you looking for? I may be able to help.

I’ve actually already found your github repo (harris-chris/nix-development-configs/cpp-specific-toolchain and it actually almost works for my case, thank you so much.

But, I’ve encountered another problem: my goal is to use older glibc to compile a whole tree of C projects, a piece of software and all of it’s dependencies. I’ve managed to apply custom stdenv to the nixpkgs tree, but it messes with the bootstrap process and outright refuses to work.

To be specific, I’m trying to compile Qemu to be as portable as possible, so ideally I need to recompile all of it’s dependencies - SDL2, x11, alsa, pixman, so on.

I think I might be able to pull it off by applying stdenv overlay to a specific list of packages, not a whole nixpkgs tree. But, right now, I could not get it to work as I have zero experience with nix and the learning process is a bit painfull :slight_smile:

Is the problem arising via «gcc as we build it needs a fresher glibc» mechanism?

And which of those things you need to be fresher than the Nixpkgs revision contemporary with the glibc version you want?

No, it was triggering something like assertion isFromBootstrapFiles failed.

Good catch, I probably don’t need anything to be really really fresh, but it would be nice. I should try it and see how it goes. I suspect that there might be a lot of work to patch CVEs in old nixpgks packages.

I mean, you can start with an older checkout and override things forward (possibly using the packages from a newer checkout…)

As for CVEs, I guess it depends on your threat model — and you have some upper bounds on success rate; glibc has had recent CVEs of its own, and some of the new versions of other stuff wlll probably want fresh glibc, so… it’s a non-negligible project to get a good overview…

1 Like

I think that that personal repo stuff is an earlier stage of my experimenting with this issue, I have the final thing on the work system. It’s a set of stdenvs, each representing a GCC and glibc version, so possibly what you need. I’ll put it up here in the next couple of days.


The way I did this is actually quite simple:

  1. I got some older glibcs and gccs from older nixpkgs revs:
glibc_2_18 = (import (builtins.fetchGit {
    name = "glibc_2_18";
    url = "";
    ref = "refs/heads/nixpkgs-unstable";
    rev = "ab6453c483e406b07c63503bca5038838c187ecf";
}) { inherit system; }).glibc;

gcc_8_3_0 = (import (builtins.fetchGit {
   name = "gcc_8_3_0";
   url = "";
   ref = "refs/heads/nixpkgs-unstable";
   rev = "a9eb3eed170fa916e0a8364e5227ee661af76fde";
}) { inherit system; }).gcc-unwrapped;

Nix Package Versions is a good resource for finding older package versions within the nixpgks history.

  1. I created a function which puts together one of these older gccs with an older glibc:
getCustomGccStdenv = customGcc: customGlibc: origStdenv: { pkgs, ... }:
  with pkgs; let
    compilerWrapped = wrapCCWith {
      cc = customGcc;
      bintools = wrapBintoolsWith {
        bintools = binutils-unwrapped;
        libc = customGlibc;
    overrideCC origStdenv compilerWrapped;
  1. Then I applied function to the glibcs/gccs to create some gcc/glibc combinations:
gcc_8_3_0_glibc_2_18 = getCustomGccStdenv
        gcc_8_3_0 glibc_2_18 pkgs.stdenv pkgs;
  1. … then passed that into my derivations. If you’re re-building existing nixpkgs derivations, then you can use override to pass the custom stdenv in, like pkgs.examplePkg.override { stdenv = gcc_8_3_0_glibc_2_18; };
    (see Overriding | nixpkgs) for more info on this. If you need all the dependencies of your target package to be re-built with the older gcc/glibc, then you might need to override the stdenv in pkgs with the custom stdenv.

I’m not sure if that precisely addresses your problem because the whole thing is quite fiddly, older nixpkgs revs don’t necessarily have the same API as newer ones so it requires tweaking on a case-by-case basis.

If any of that isn’t clear then please let me know.