Fhs nix-shell with older glibc (2.27) segfaults on basic system programs

Development
1

To test the compatibility of binaries I want to distribute with other (older) linux systems (mostly FHS based, but also “the other way around”: i.e. my gitlab-runner is on Arch, and I want to run/test on nixos), I’m trying to use an fhs nix-shell like this one:

# fhsUser.nix
let
  pkgs = import (builtins.fetchGit {
    # glibc-2.27;                                                 
    url = "https://github.com/NixOS/nixpkgs/";                       
    ref = "refs/heads/nixpkgs-unstable";                     
    rev = "2158ec610d90359df7425e27298873a817b4c9dd";                                           
  }) {}; in
# { pkgs ? import <nixpkgs> {} }:
(pkgs.buildFHSUserEnv {
  name = "stdxenv";
  targetPkgs = pkgs: with pkgs; [
    coreutils
  ];
  multiPkgs = pkgs: with pkgs; [
    zlib
    curl
    utillinux
    harfbuzz
    cairo
    pango
    gdk_pixbuf
    glib # libgio?
    epoxy 
    atk
    gtk3
    "vscode-fhs"
  ];
  runScript = "bash";
}).env

However, pretty much everything I’m trying to run in this shell segfaults.
I found some similar references (glibc-2.30 libraries link to glibc-2.27 · Issue #84043 · NixOS/nixpkgs · GitHub, bash segfaults on 20.03 when entering nix-shell using buildFHSUserEnv and 19.09 nixpkgs · Issue #85972 · NixOS/nixpkgs · GitHub), but none from which I could recognise a more or less direct solution (possibly in my “noobness”).

Any ideas?

2

Why such an old nixpkgs commit?

$ git describe 2158ec610d
18.09-beta-60049-g2158ec610d9

glibc has very high compatibility assurance but only for upgrades. If you try running stuff with older glibc than what you used during build, you’ll often run into problems with missing symbols.

3

Maybe my description was a bit convoluted, but that’s exactly the point:

I want my binaries to be compatible with older systems, so I want to build them on an old glibc, which I will do in my CI in containers (either on nixos or other).

I then want to test (on nixos) whether indeed the binaries can be run on old glibc environments and newer, so I want to specifically use old glibc-based shell envs.

The issue came up in the first place because my stable nixos had a glibc-2.31 and my CI (up-to-date Arch linux) built my binary on glibc-2.32, which I then couldn’t run on my nixos machine. So I realised that I had to build my binaries on “relatively old” glibc’s for max compatibility.

As a side-note, in this case we’re talkin a flutter-desktop app, so there are a few more deps there.

4

Ah, I somehow thought the FHS was consumer of the builds, not producer. Another point to think about are any other dependencies/libraries, too. They tend to be more sensitive to correct version than glibc. (In particular, major version changes are usually a problem, even if it’s an upgrade.)

Generally, if you want binaries for a particular (old) system, I would use that system’s tools/libs/etc. to build them. People often use docker or LXC for that with the particular distro inside, as that approach gives quite good tradeoffs.

5

Thanks again for the quick reply, let me clarify a bit more

I want to build them on an old glibc , which I will do in my CI in containers (either on nixos or other).

I.e. the build is de-facto done on older glibc (native FHS (Arch), nixos, or container (FHS))

The test or run of the binary (built on another system) I want to do on nixos, in different glibc versions.
For this I want to use fhs shell, but it doesn’t work as expected, because it crashes most programs.

What I seek is a solution to the fhs shell not working as expected, it basically segfaults on any call, even simple ones like which bash.

One more reason to want a working fhs shell is that I’d like to easily be able to run things like a flutter environment that is installed in the official way (e.g. in ~/devel/flutter) and uses vanilla install scripts that rely on FHS.)