glibc: use libgcc from pkgsHostHost #259964
Conversation
glibc depends on buildPackages.glibc for locale things. buildPackages.glibc depended on buildPackages.libgcc, which, since it's GCC, depends on the target's bintools, which depend on the target's glibc, which, again, depends on buildPackages.glibc, causing an infinute recursion when evaluating buildPackages.glibc when glibc hasn't come from stdenv (e.g. on musl). It's unlikely that buildPackages.glibc needs anything to do with the target, so I've broken the cycle by having it use pkgsHostHost.libgcc. This fixes cross compilation from musl to glibc.
alyssais
added
6.topic: cross-compilation
ofborg
bot
added
10.rebuild-darwin: 0
|
This whole situation makes me sad... #132343 really needs to be finished. |
Hey at least I got mainline nixpkgs to use at least one separately-built target library. Previously the record was zero. One step at a time... |
There was a problem hiding this comment.
Nice catch!
But do we really need to rename the parameter here? The diff is much smaller without the rename from libgcc to libgccHostHost.
It's unlikely that buildPackages.glibc needs anything to do with the target
Indeed. Although a more direct fix might be to simply define the top-level libgcc to be if host!=target then pkgsHostHost.libgcc else callPackage ... to fix the problem at the source.
I have general feeling that there is a whole class of packages (the overwhelming majority) where this sort of thing ought to be done, because the package has no meaningful notion of "target platform". In fact in the long run I think that ought to be the default, and packages ought to have to declare that they have a meaningful target platform in order to avoid this behavior. But I digress...
This fixes cross compilation from musl to glibc.
Could you let me know the attrname you use as a reproducer test for this bug? It would make a nice addition to tests.cross.sanity, which is my collection of cross-compilation smoke tests (since we still don't have meaningful CI for the vast majority of cross compilation configurations). You seem to come across a lot of these interesting corner cases; don't hesitate to add them there if you think there isn't any existing coverage.
I had it that way originally, but I decided it was confusing to keep it with the same name, because it could end up being passed in through callPackage automatically, which wouldn't be correct. I think it's better to be explicit and avoid callPackage naming conflicts. |
pkgsMusl.pkgsCross.gnu64.hello on x86_64-linux is a reproducer |
ghost
mentioned this pull request
|
@alyssais thank you so much for tracking down this circular dependency! However breaking the chain by taking libgcc from pkgsHostHost adds considerable additional complexity (which really should be explained in the codebase if we go that route -- as it stands this PR doesn't add anything to the code explaining why Would you consider this alternative fix? (Note I am still building it to verify that it works): IMHO the alternative adds no extra complexity, and actually makes |
This is an alternative resolution of the problem identified in #259964 which stated that "glibc depends on buildPackages.glibc for locale things. buildPackages.glibc depended on buildPackages.libgcc, which, since it's GCC, depends on the target's bintools, which depend on the target's glibc, which, again, depends on buildPackages.glibc, causing an infinute recursion when evaluating buildPackages.glibc when glibc hasn't come from stdenv (e.g. on musl)." The fact that we use pkgsBuildHost.glibc instead of pkgsBuildBuild.glibc to generate the locales has always been a gross hack. If we simply remove the gross hack the circularity goes away.
|
Closing this because that one is merged. |
Yes we really need to do this. Let's make an issue for it. #263640 |
Description of changes
glibc depends on buildPackages.glibc for locale things.
buildPackages.glibc depended on buildPackages.libgcc, which, since it's GCC, depends on the target's bintools, which depend on the target's glibc, which, again, depends on buildPackages.glibc, causing an infinute recursion when evaluating buildPackages.glibc when glibc hasn't come from stdenv (e.g. on musl).
It's unlikely that buildPackages.glibc needs anything to do with the target, so I've broken the cycle by having it use
pkgsHostHost.libgcc.
This fixes cross compilation from musl to glibc.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)