ghc: mark broken for musl + integer-simple builds#130441
ghc: mark broken for musl + integer-simple builds#130441cdepillabout merged 9 commits intoNixOS:haskell-updatesfrom
Conversation
0f1392b to
2bd7378
Compare
|
@nh2 @sternenseemann I'd like to do the following two things with this PR:
I meant to do this in #129606, but I couldn't figure out exactly what is expected to be working. I'm hoping you guys would be able to help me out with this. Looking at the latest Hydra evaluation for #129606, we can see what is not working for GHC musl integer-simple: https://hydra.nixos.org/eval/1686753?filter=integer-simple&compare=1686725 Here's a summary:
This is mostly for @sternenseemann, but maybe it makes sense for us to add a job like We should probably also have a separate job for |
There was a problem hiding this comment.
This is almost certainly incorrect and should not be merged as-is.
Two problems with this:
-
For
broken, I couldn't figure out what the logic should be.I think that GHC is broken when:
- you're using
integer-simple - you're compiling with
musl - you're not linking libraries statically
On Hydra, jobs like
pkgsMusl.haskell.compiler.integer-simple.{ghc884,ghc8104,ghc901}.x86_64-linuxare failing to compile, which should match this configuration.However, I think GHC is building correctly when:
- you're using
integer-simple - you're compiling with
musl - you are linking libraries statically
On Hydra, jobs like
pkgsStatic.haskell.packages.integer-simple.ghc8104.{hello,lens,random}.x86_64-linuxare build successfully (which should be using a GHC that matches this configuration).Is there some easy way to check whether or not libraries are being linked statically?
- you're using
-
I imagine
hydraPlatformsis just incorrect here. It'd probably be better just remove the things we know not to be working inrelease-haskell.nix.
There was a problem hiding this comment.
Is there some easy way to check whether or not libraries are being linked statically?
targetPlatform.isStatic
I imagine hydraPlatforms is just incorrect here. It'd probably be better just remove the things we know not to be working in release-haskell.nix.
Agreed, at the very least make meta into a rec set and do:
${if broken then "hydraPlatforms" else null} = lib.platforms.none;
or something like that.
|
@nh2 @sternenseemann The more I look into this, the more questions I end up having. Here's two more questions:
|
ea38ec1 to
efc6f9b
Compare
|
Alright, I've tried to clean up the Here's what I've done in this PR:
|
AFAIK this is mostly historically baggage. GHC's build system doesn't like to be reverse bootstrapped, so compiling 8.8.4 with 8.10.2 would normally fail. However at some point there were problems with the binary 8.6.5 on some platforms which lead to 8.10.2 being used and a patch introduced which allowed reverse bootstrapping. The condition was apparently introduced to avoid a full rebuild at the time. Since reverse bootstrapping works well enough, I'd suggest we use 8.10.2 for everything in the future, so we can remove |
Note that these packages are not actually built with the We'd need a different test to check if these compilers are working as intended. |
pkgs/top-level/release-haskell.nix
Outdated
There was a problem hiding this comment.
With removePlatforms the need to specify the platforms explicitly should be removed and we could use accumulateDerivations again here.
There was a problem hiding this comment.
Ah, good catch. I fixed this in fb722f4.
Ah, this makes sense. I didn't realize that GHC doesn't like to be reverse-bootstrapped.
I played around in the repl a little bit to try to confirm this: It looks like this compiler is a dynamically-linked musl GHC, although it is not the same compiler as $ nix-build /nix/store/7ys2bpnfvgn05pcqq0ma6dy5q2352imk-x86_64-unknown-linux-musl-ghc-8.10.4.drv
/nix/store/bzbb6mrb9k53hcabzdq1rplsabvm78wb-x86_64-unknown-linux-musl-ghc-8.10.4
$ file /nix/store/bzbb6mrb9k53hcabzdq1rplsabvm78wb-x86_64-unknown-linux-musl-ghc-8.10.4/lib/x86_64-unknown-linux-musl-ghc-8.10.4/bin/ghc
/nix/store/bzbb6mrb9k53hcabzdq1rplsabvm78wb-x86_64-unknown-linux-musl-ghc-8.10.4/lib/x86_64-unknown-linux-musl-ghc-8.10.4/bin/ghc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/mkd3yc1qgkq35xpjy367p4l9zwa11bcn-musl-static-x86_64-unknown-linux-musl-1.2.2/lib/ld-musl-x86_64.so.1, not stripped
$ ldd /nix/store/bzbb6mrb9k53hcabzdq1rplsabvm78wb-x86_64-unknown-linux-musl-ghc-8.10.4/lib/x86_64-unknown-linux-musl-ghc-8.10.4/bin/ghc | grep -i libc
libc.so => /nix/store/mkd3yc1qgkq35xpjy367p4l9zwa11bcn-musl-static-x86_64-unknown-linux-musl-1.2.2/lib/libc.soFor It appears that both $ nix-build /nix/store/313pagmnlqd7jw86jv5vccld7nwh4xws-ghc-8.10.4.drv
/nix/store/g42rbg25ify95a1k0057s3s3rkrxhaqz-ghc-8.10.4
$ file /nix/store/g42rbg25ify95a1k0057s3s3rkrxhaqz-ghc-8.10.4/lib/ghc-8.10.4/bin/ghc
/nix/store/g42rbg25ify95a1k0057s3s3rkrxhaqz-ghc-8.10.4/lib/ghc-8.10.4/bin/ghc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/pqnpr7frjq2d28yalzy9di409ph1gnim-musl-1.2.2/lib/ld-musl-x86_64.so.1, not stripped
$ ldd /nix/store/g42rbg25ify95a1k0057s3s3rkrxhaqz-ghc-8.10.4/lib/ghc-8.10.4/bin/ghc | grep -i libc
libc.so => /nix/store/pqnpr7frjq2d28yalzy9di409ph1gnim-musl-1.2.2/lib/libc.so (0x00007f58ccb9d000)So it looks like the GHCs used for building However, I think I understand what you're trying to say. I imagine it is possible for a non-musl-linked GHC to be able to create binaries that are linked to musl. The (As you probably can tell, I don't know anything about cross-compilation, so I'm definitely in over my head here. My original goal with this PR was just to get rid of the broken |
There was a problem hiding this comment.
Okay, so I think I gave you wrong advice on this since I was confused about pkgsMusl: In contrast to pkgsStatic it compiles natively using musl, so also buildPackages uses musl:
nix-repl> pkgsMusl.buildPackages.stdenv.hostPlatform.isMusl
true
nix-repl> pkgsStatic.buildPackages.stdenv.hostPlatform.isMusl
false
This means that the problem is not the target platform of GHC, but its host platform. The result is a simpler condition:
| # integer-simple builds broken when compiling with non-static musl. | |
| # See https://github.com/NixOS/nixpkgs/pull/129606#issuecomment-881323743. | |
| broken = enableIntegerSimple && targetPlatform.isMusl && !targetPlatform.isStatic; | |
| # integer-simple builds are broken when GHC links against musl. | |
| # See https://github.com/NixOS/nixpkgs/pull/129606#issuecomment-881323743. | |
| broken = enableIntegerSimple && hostPlatform.isMusl; |
There was a problem hiding this comment.
That makes sense. I rebased and made this fix in 67b38e144a681c34.
pkgs/top-level/release-haskell.nix
Outdated
There was a problem hiding this comment.
Doesn't it just time out? I would have guessed it should work.
There was a problem hiding this comment.
Ah, yeah, I wasn't sure what was going on here.
With the current status of this PR, I removed this line:
diff --git a/pkgs/top-level/release-haskell.nix b/pkgs/top-level/release-haskell.nix
index 636f0f2b15e..14288b372cb 100644
--- a/pkgs/top-level/release-haskell.nix
+++ b/pkgs/top-level/release-haskell.nix
@@ -258,7 +258,7 @@ let
pkgsMusl.haskellPackages =
removePlatforms
[
- "aarch64-linux" # aarch64 does not appear to be supported
"x86_64-darwin" # musl only supports linux
]
{I then reran hydra-eval-jobs:
$ hydra-eval-jobs -I . pkgs/top-level/release-haskell.nixHere's the diff comparing running hydra-eval-jobs on release-haskell.nix with the current status of this PR vs. making the above change:
--- current-state 2021-07-24 14:28:55.013105845 +0900
+++ building-on-aarch64 2021-07-24 15:37:46.510185699 +0900
@@ -345373,6 +345373,9 @@
"system": "x86_64-linux",
"timeout": 36000
},
+ "pkgsMusl.haskellPackages.hello.aarch64-linux": {
+ "error": "error: Failed to evaluate ghc-8.10.4: «unsupported»: is not supported on ‘aarch64-linux’"
+ },
"pkgsMusl.haskellPackages.hello.x86_64-linux": {
"description": "Hello World, an example package",
"drvPath": "/nix/store/15dsk39ajxxk71fvp92jjp3cz56qafj8-hello-1.0.0.2.drv",
@@ -345390,6 +345393,9 @@
"system": "x86_64-linux",
"timeout": 36000
},
+ "pkgsMusl.haskellPackages.lens.aarch64-linux": {
+ "error": "error: Failed to evaluate ghc-8.10.4: «unsupported»: is not supported on ‘aarch64-linux’"
+ },
"pkgsMusl.haskellPackages.lens.x86_64-linux": {
"description": "Lenses, Folds and Traversals",
"drvPath": "/nix/store/5yxm6fhlaiq6lw29aypzx5rvir6qirq4-lens-4.19.2.drv",
@@ -345407,6 +345413,9 @@
"system": "x86_64-linux",
"timeout": 36000
},
+ "pkgsMusl.haskellPackages.random.aarch64-linux": {
+ "error": "error: Failed to evaluate ghc-8.10.4: «unsupported»: is not supported on ‘aarch64-linux’"
+ },
"pkgsMusl.haskellPackages.random.x86_64-linux": {
"description": "Pseudo-random number generation",
"drvPath": "/nix/store/k7fhjmvf6ygqm3izzc0i94d2j2rzxib0-random-1.2.0.drv",There was a problem hiding this comment.
Oh yeah, I see why this happens: We can only natively bootstrap GHC with musl on x86_64-linux because we only have a musl bindist for this platform since upstream doesn't provide musl builds for aarch64.
With this in mind you probably should just clarify the comment and keep it as is.
You are right, I got confused a bit and forgot that it is actually possible to natively compile using musl in nixpkgs. This is actually pretty good because it means our issue is not as weird as thought and the
Not for
Yes, this is what happens for It's btw quite easy to check these things at the source in nixpkgs/pkgs/top-level/stage.nix Lines 178 to 193 in 3b12024
nixpkgs/pkgs/top-level/stage.nix Lines 228 to 248 in 3b12024 |
|
We should really write a comment above This confuses people regularly. |
For native (non-cross) compilation as GHC installs not only the compiler, but also static libraries of its dependencies (say, At leat that's my current understanding; maybe @bgamari or @angerman can state whether it's really on point. For cross-compilation like |
Well since |
Ah, I didn't expect nix-repl> ghc
«derivation /nix/store/qgp4692xsf4gjpm0ihjzq1wi0yydfh8l-ghc-8.10.4.drv»
nix-repl> haskell.compiler.ghc8104
«derivation /nix/store/qgp4692xsf4gjpm0ihjzq1wi0yydfh8l-ghc-8.10.4.drv»
nix-repl> pkgsStatic.buildPackages.ghc
«derivation /nix/store/qgp4692xsf4gjpm0ihjzq1wi0yydfh8l-ghc-8.10.4.drv»
nix-repl> pkgsStatic.buildPackages.haskell.compiler.integer-simple.ghc8104
«derivation /nix/store/7ys2bpnfvgn05pcqq0ma6dy5q2352imk-x86_64-unknown-linux-musl-ghc-8.10.4.drv»
nix-repl> pkgsStatic.buildPackages.haskell.compiler.ghc8104
«derivation /nix/store/62lbrqaqh68pa3bigd064midzsz922wb-x86_64-unknown-linux-musl-ghc-8.10.4.drv»
nix-repl> pkgsStatic.ghc
«derivation /nix/store/62lbrqaqh68pa3bigd064midzsz922wb-x86_64-unknown-linux-musl-ghc-8.10.4.drv»For nix-repl> pkgsMusl.buildPackages.ghc
«derivation /nix/store/313pagmnlqd7jw86jv5vccld7nwh4xws-ghc-8.10.4.drv»
nix-repl> pkgsMusl.buildPackages.haskell.compiler.ghc8104
«derivation /nix/store/313pagmnlqd7jw86jv5vccld7nwh4xws-ghc-8.10.4.drv»
nix-repl> pkgsMusl.ghc
«derivation /nix/store/313pagmnlqd7jw86jv5vccld7nwh4xws-ghc-8.10.4.drv»
nix-repl> pkgsMusl.haskell.compiler.ghc8104
«derivation /nix/store/313pagmnlqd7jw86jv5vccld7nwh4xws-ghc-8.10.4.drv»Also, thanks for the pointers to @nh2 Thanks for the clarification on pkgsMusl native compilation and pkgsStatic cross compilation. That all makes complete sense. |
…before static This is just a small reorganization.
These aarch64 builds appear to be timing out.
…ages The statically-linked Haskell packages on Darwin are not currently working because libiconv is not building statically on Darwin. The statically-linked Haskell packages on aarch64 are timing out on Hydra.
integer-simple GHCs appear to be broken when linking against musl and non-static-linking.
This is helpful to get a small cache going for people who want musl-enabled packages.
fb722f4 to
75420df
Compare
Niklas fixed a regression, the binary GHC started to segfault with musl due to a new ABI incompatibility. 20.05 was a long time ago and any number of things could have changed in upstream projects as well as nixpkgs. It doesn't really help that integer-simple probably should work, it's just a matter of working out what the build system is doing. I think Niklas had a sound theory what the problem was and it may or may not be easy to fix. |
|
@nomeata Oh, and I imagine you likely know this, but we of course would like pkgsMusl integer-simple to be working. If you wanted to investigate and potentially send a patch, we would definitely merge it in! |
|
I am just a grateful user, and usually out of my depth fixing these problems, so the most I sometimes can do is cargo cult something based on random guesses or patches I see floating around But with ~/build/nixpkgs $ git diff
diff --git a/pkgs/development/compilers/ghc/8.8.4.nix b/pkgs/development/compilers/ghc/8.8.4.nix
index e2a65a19791..cd7f5e709df 100644
--- a/pkgs/development/compilers/ghc/8.8.4.nix
+++ b/pkgs/development/compilers/ghc/8.8.4.nix
@@ -125,7 +125,7 @@ let
# Splicer will pull out correct variations
libDeps = platform: lib.optional enableTerminfo ncurses
++ [libffi]
- ++ lib.optional (!enableIntegerSimple) gmp
+ ++ [gmp]
++ lib.optional (platform.libc != "glibc" && !targetPlatform.isWindows) libiconv;
toolsForTarget = [
@@ -343,7 +343,7 @@ stdenv.mkDerivation (rec {
# integer-simple builds are broken when GHC links against musl.
# See https://github.com/NixOS/nixpkgs/pull/129606#issuecomment-881323743.
- broken = enableIntegerSimple && hostPlatform.isMusl;
+ # broken = enableIntegerSimple && hostPlatform.isMusl;
};
dontStrip = (targetPlatform.useAndroidPrebuilt || targetPlatform.isWasm);it at least links Cabal and then makes progress with the build. Maybe building GHC now needs |
|
Yeah, iirc that was Nilkas' theory as well. Adding Can maybe look into this later after I've finished compiling GHCJS :p |
|
Ha, with that, |
as per discussion on NixOS#130441 (comment) this seems to be enough to make ``` nix-build -A pkgsMusl.haskell.packages.integer-simple.ghc884.hello ``` work again. This is likely not the right patch (maybe `gmp` should be `nativeBuildInput`? Or a propagated build input from the boot ghc?), but this way I we can discuss (and I can pull the patch into my project...)
|
And my project (building a relatively large Haskell binary statically) also works again with that. So I think this can be solved. Shall we continue the discussion on #138429? |
|
@nomeata For the background:
The reason why it worked was pure luck (as far as I can tell): In the past the In my commit da1cf8c I deleted the no-longer-working But that one nobody had made work with |
|
Thanks! That makes sense. But it seems to be reach now? Or is a fix along the lines of #138429 the wrong direction? |
Retaining here the actual error message from the build log in case Hydra cleans that up in the future: That is, the The first thing that gets built is the So the situation is that we're building an During that build, a bootstrapping And that (Background interlude: GHC HQ could choose to build their musl compiler bindist [our From here, there are 2 alternative hypotheses:
Both hypotheses are consistent with the fact that PR #138429 fixes the build, probably because putting To check which hypothesis to follow, let's check whether the GHC HQ musl bindist is linked against Yes, it is. So we are in hypothesis 1. Thus I think we should investigate:
Doing a bit of that investigation myself here:
On the nix side: It looks like nix puts The It has a handy comment on top (apparently I wrote it here): nixpkgs/pkgs/development/compilers/ghc/8.10.2-binary.nix Lines 146 to 157 in 28f28c2 The mentioned note nixpkgs/pkgs/development/compilers/ghc/8.10.2-binary.nix Lines 217 to 223 in 28f28c2
I remarked further up. Following the linked ticket, I pointed out
So that's probably the root cause of this problem. It looks like GHC HQ did not intend to make the musl bindists with Summary
Phew. This message got longer than I originally planned. |
|
Wow, thanks a lot! Such comments are immensely helpful for those of use still learning (like me…) |
That does not seem to work, I still get the linker error after building Cabal. |
Indeed: --- a/pkgs/development/compilers/ghc/8.10.2-binary.nix
+++ b/pkgs/development/compilers/ghc/8.10.2-binary.nix
@@ -154,7 +154,7 @@ stdenv.mkDerivation rec {
# (Note that for packaging the `-binary` compiler, nixpkgs does not care
# about whether or not `gmp` is used; this comment is just here to explain
# why the `gmp` dependency exists despite what the release page says.)
- ++ lib.optionals stdenv.hostPlatform.isMusl [ gmp ]; # musl bindist needs this
+ ++ lib.optionals stdenv.hostPlatform.isMusl [ gmp.out ]; # musl bindist needs thisReading: It looks like Maybe there's other things it can help with -- happy for any pointers! So far I've tested what happens when i remove it completely: - ++ lib.optionals stdenv.hostPlatform.isMusl [ gmp ]; # musl bindist needs thisFirst, When I put it into - ++ lib.optionals stdenv.hostPlatform.isMusl [ gmp ]; # musl bindist needs this
+ ;
+ buildInputs = [ gmp ];then So
|
I have now reflected that in PR #138523 in our packaging of |
I have made PR #138524, which switches If we're lucky, this will fix the problems. I will need others to test if it works well though, as I don't have much time currently. |
* Experiment: Bump nixpkgs to latest master This is to see if there are problems coming up. Some of the things in nix/haskell-packages.nix can probably be cleaned up now. Originally https://github.com/dfinity-lab/ic-ref/commit/dce1286a900525607fcc21171b82940e3ec3385f * Bump again Originally https://github.com/dfinity-lab/ic-ref/commit/b43f83609fd3a99e0a8ecd8700f4baee0c53b863 * Bump once more Originally https://github.com/dfinity-lab/ic-ref/commit/a0746ed7be49c8f1619e5b75ba84d5c832730cf8 * Fix merge issue * Fix path * Back to master * Try winter master * Remove many haskell package changes * More simplification and upstream cache use * Update freeze file * Less versionoverrides needed * Remove nix/haskell-packages, more DNRY * Fix patch handling * Add .gitattributes to mark generated files as such * s/ / / * Run github actions with ghc-8.10.7 * Fix docs jobs * Fix docs jobs some more * Update cabal.project * Bump candid some more * Checkout before setting up the cache * Fix cabal keys * Don’t set active-repositories in freeze file * Rename workflow * naersk changed it seems * Try pkgsStatic, not pkgsMusl as the latter doesn’t seem to work any more since NixOS/nixpkgs#130441 * Fix static cborg build * Try static-haskell-nix * Revert "Try static-haskell-nix" This reverts commit b375ad4. * Revert "Try pkgsStatic, not pkgsMusl" This reverts commit d1f64f1. * Try pkgsMusl again pulling in NixOS/nixpkgs#138429 * Update freeze file * Right GHC version * Try NixOS/nixpkgs#138524
…endency. GHC HQ switched the musl bindists from gmp to `integer-simple` with GHC >= 8.10.6, but this was not reflected in the nixpkgs update: * commit 6f12424: ghc: 8.10.5-binary -> 8.10.7-binary From PR NixOS#135453 See also NixOS#130441.
This fixes musl+integer-simple, see NixOS#130441. Co-Authored-By: sternenseemann <sternenseemann@systemli.org>
This fixes musl+integer-simple, see #130441. Co-Authored-By: sternenseemann <sternenseemann@systemli.org>
Motivation for this change
This PR correctly marks the GHC musl integer-simple builds as broken.
See #129606 (comment).
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)