Eval failure: python3Packages.pyglet hardcodes glibc dependency even on non-Linux platforms

[Rhys-T]

Describe the bug

python3Packages.pyglet hardcodes the paths to various libraries it depends on to work around #7307. Unfortunately, it assumes that libc should always be provided by the glibc derivation, regardless of what platform you're on. Since glibc is Linux-only, this keeps pyglet from even evaluating on other platforms, like macOS. I just get:

       error: Package ‘glibc-nolibgcc-2.40-36’ in /nix/store/73cnf2k7mji95fcflvay15pdw4skhhk5-source/pkgs/development/libraries/glibc/default.nix:214 is not available on the requested hostPlatform:
         hostPlatform.config = "x86_64-apple-darwin"
         package.meta.platforms = [
           "aarch64-linux"
           "armv5tel-linux"
           "armv6l-linux"
           "armv7a-linux"
           "armv7l-linux"
           "i686-linux"
           "loongarch64-linux"
           "m68k-linux"
           "microblaze-linux"
           "microblazeel-linux"
           "mips-linux"
           "mips64-linux"
           "mips64el-linux"
           "mipsel-linux"
           "powerpc64-linux"
           "powerpc64le-linux"
           "riscv32-linux"
           "riscv64-linux"
           "s390-linux"
           "s390x-linux"
           "x86_64-linux"
         ]
         package.meta.badPlatforms = [ ]
       , refusing to evaluate.

pyglet itself is marked as being able to build on Darwin (inherited from mesa) - it's just the fact that it's pulling in the wrong libc that's causing problems.

Steps To Reproduce

Steps to reproduce the behavior:

1. nix build nixpkgs\#python3Packages.pyglet
   Or without flakes: nix-build '<nixpkgs>' -A python3Packages.pyglet

Expected behavior

pyglet should build and install correctly.

Additional context

If I remove the reference to glibc and replace the path with /usr/lib/libc.dylib (a symlink which eventually resolves to /usr/lib/libSystem.B.dylib), it seems to build and run correctly on macOS/darwin.

(python3Packages.pyglet.override {
    glibc = "<dummy>";
}).overridePythonAttrs (old: {
    postPatch = builtins.replaceStrings ["<dummy>/lib/libc.dylib.6"] ["/usr/lib/libc.dylib"] (old.postPatch or "");
}

That technically makes it impure again, but as far as I can tell that's how libc/libSystem is always handled on macOS, since the library is considered the stable kernel interface there rather than the underlying system calls. (The stdenv.cc.libc derivation for Darwin doesn't even have any files in it.) I'm not sure how to handle it generically, though, and I haven't had a chance to test whether that path works on newer macOS versions where the library only exists inside the dyld cache. Edit: Just tested ctypes.CDLL('/usr/lib/libc.dylib') on a newer system using the python3 from Apple's command-line developer tools package, and it seems to work correctly despite the library not actually existing at that path.

I hope I'm filing this correctly - I went back and forth on whether this should use the "bug report" or "build failure" template, and finally decided on this since it was technically an evaluation failure.

Metadata

• system: "x86_64-darwin"
• host os: Darwin 19.6.0, macOS 10.15.7
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.24.10
• channels(root): "nixpkgs"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixpkgs

Note that I was using the Nixpkgs flake rather than the somewhat old nixpkgs channel on my machine when I discovered this, but it fails the same way with either one.

Notify maintainers

I don't see any meta.maintainers listed for python3Packages.pyglet. The hardcoded library path stuff was originally added by @timokau in 446ac90 (#62150).

---

Note for maintainers: Please tag this issue in your PR.

---

Add a 👍 reaction to issues you find important.