Open Gabriella439 opened 4 years ago
Hey Gabriel, thanks for the report.
The problem is in this line: https://github.com/nh2/static-haskell-nix/blob/d24dea3d46a727e1cd93e67458ce2768109efe0a/survey/default.nix#L460
The issue here seems to be that, probably via cabal2nix -> fetchurl -> curl -> zlib
, somewhere zlib.static
is used, and that is not overridable:
$ nix-shell -p 'pkgs.zlib.override {}'
# works fine
$ nix-shell -p 'pkgs.zlib.static.override {}'
error: attribute 'override' missing, at (string):1:94
Now I just need to find out what to do about it...
It's going to be this:
{
zlib = (super.zlib.override {
static = true;
shared = false;
# Don’t use new stdenv zlib because
# it doesn’t like the --disable-shared flag
stdenv = super.stdenv;
}).static;
}
This was already accidentally fixed in nixpkgs master with https://github.com/NixOS/nixpkgs/pull/74485/files#diff-d125f8cf97a8da782a42f2f648415cd9L92 which removes the use of .static
in favour of splitStaticOutput = false;
inside the .override
.
FYI @malbarbo @dtzWill @matthewbauer Check out the above and the previous two comments, it appears that we must never use .static
outputs in things like static.nix
because they are not overridable.
When I cherry-pick that, or use nixpkgs master
, the next challenge I face is this infinite recursion:
I think I found the problem: the revision of nixpkgs
that static-haskell-nix
is currently using is responsible for the infinite recursion. When I update the nixpkgs
revision to the latest master
the evaluation errors disappear and the only error I have left is the same one as in https://github.com/nh2/static-haskell-nix/issues/29
Here is the change to the reproducing code that now instantiates successfully:
let
compiler = "ghc865";
nixpkgs = builtins.fetchTarball {
url = "https://github.com/nh2/nixpkgs/archive/83fd89945d355892e0e95747c9a2c519491c1600.tar.gz";
sha256 = "05jybj66gdzdmjgawa2a72b6pf669rfb6pljhlc3lpyq6dlnw87d";
};
static-haskell-nix = builtins.fetchTarball {
url = "https://github.com/nh2/static-haskell-nix/archive/c360f2a15f6947b411ecbd7ebaea925f6dbd68df.tar.gz";
sha256 = "0y6ppiagh6dbvdhhnrq572xnw2yzn6d0gcmajrfdgdfwhsl21g95";
};
overlay = pkgsNew: pkgsOld: {
haskell = pkgsOld.haskell // {
packages = pkgsOld.haskell.packages // {
"${compiler}" = pkgsOld.haskell.packages."${compiler}".override (old: {
overrides = pkgsNew.haskell.lib.packageSourceOverrides {
dhall = "1.29";
};
}
);
};
};
};
normalPkgs = import nixpkgs {
system = "x86_64-linux";
config = { };
overlays = [ overlay ];
};
staticHaskell = import "${static-haskell-nix}/survey/default.nix" {
inherit compiler normalPkgs;
};
in
staticHaskell.all.dhall
@Gabriel439 Ah that's great.
Do you happen to know which nixpkgs
commit is the fix?
I currently cannot (trivially / have not tried yet) upgrade to latest nixpkgs master because my nightly CI shows that the latest master has important Haskell packages like darcs
marked as broken:
https://buildkite.com/nh2/static-haskell-nix/builds/341#438409a8-05e1-48a6-8000-b30d5511679f
error: Package ‘darcs-2.14.2’ in /nix/store/lc4aal3h7iqz0cbr6dfpjnrbnig76whk-source/pkgs/development/haskell-modules/hackage-packages.nix:64807 is marked as broken, refusing to evaluate.
My plan so far was to wait until nixpkgs has figured that out, but if it happens to be darcs-specific (as evaluations show only the first error), we could also just disable that for now.
@nh2: 83fd89945d355892e0e95747c9a2c519491c1600
should work
@Gabriel439 No I mean whether you happen to know which specific commit got rid of the infinite recursion (then I could consider picking it to not break darcs and whatever other Haskell stuff may be broken in current nixpkgs
master).
~Actually, I think I know which commit is inolved here (fromt the Github backlink further up):~
~https://github.com/NixOS/nixpkgs/pull/74485#pullrequestreview-351188110~
Sorry, that was for the missing attribute
, not the infinite recursion.
Looking into this, I hit https://github.com/NixOS/nixpkgs/pull/83825, but you already took care of that.
Here is the change to the reproducing code that now instantiates successfully:
@Gabriel439 That doesn't work for me:
% nix-instantiate issue-73-investigation-2020-01-31-2.nix -j1
building '/nix/store/42ygzdkbm8w9wlzvp8136vsh1zql4vda-all-cabal-hashes-component-dhall-1.29.drv'...
tar: */dhall/1.29/dhall.json: Not found in archive
tar: */dhall/1.29/dhall.cabal: Not found in archive
tar: Exiting with failure status due to previous errors
builder for '/nix/store/42ygzdkbm8w9wlzvp8136vsh1zql4vda-all-cabal-hashes-component-dhall-1.29.drv' failed with exit code 2
cannot build derivation '/nix/store/cq02ama8wchi75apq3mb8a08dsms8b5j-cabal2nix-dhall-1.29.drv': 1 dependencies couldn't be built
error: build of '/nix/store/cq02ama8wchi75apq3mb8a08dsms8b5j-cabal2nix-dhall-1.29.drv' failed
(use '--show-trace' to show detailed location information)
Command exited with non-zero status 100
@nh2: Yeah, I didn't get that far yet (I got stuck on the coreutils
build failure). I just meant that it fixes the evaluation failure
@nh2: Also, for that specific error you can probably fix it by s/1.29/1.29.0/
for that specific error you can probably fix it by
s/1.29/1.29.0/
Thanks, that's what I needed indeed.
I mean whether you happen to know which specific commit got rid of the infinite recursion
I bisected it; it is commit https://github.com/NixOS/nixpkgs/commit/2645e1a1eb41742905394db9d7679a1bb3343eeb by @madjar that fixed it, merged as part of https://github.com/NixOS/nixpkgs/pull/82345.
Cherry-picking it on top of my current static-haskell-nix-2020-02-05
nixpkgs branch (commit https://github.com/nh2/nixpkgs/commit/0c960262d159d3a884dadc3d4e4b131557dad116) makes the infinite recursion go away there.
I got stuck on the
coreutils
build failure
@Gabriel439 What's your plan for that? I'm pretty sure that these days you can use the nix sandbox and nix-daemon also on non-NixOS.
I now got stuck at a bad archive: input doesn't look like a Nix archive
error when trying to copy down base-compat
:
copying path '/nix/store/a1bsf33rrc7daxna17hbk1y4a61a9qxx-base-compat-0.10.5' from 'https://static-haskell-nix.cachix.org'...
bad archive: input doesn't look like a Nix archive
This was reproducible every time.
This worked around it:
% nix-copy-closure --from static-haskell-nix-ci /nix/store/a1bsf33rrc7daxna17hbk1y4a61a9qxx-base-compat-0.10.5
copying 1 paths...
copying path '/nix/store/a1bsf33rrc7daxna17hbk1y4a61a9qxx-base-compat-0.10.5' from 'ssh://static-haskell-nix-ci'...
Very suspicious.
Edit: Probably this: https://github.com/cachix/cachix/issues/251#issuecomment-606930271
The next error I encounter is due to krb5
recently breaking (and even more recently re-fixing) musl support: https://github.com/krb5/krb5/commit/b009cca2026b615ef5386faa4c0230bc27c4161d
The next error I encounter is due to
krb5
recently breaking (and even more recently re-fixing) musl support: krb5/krb5@b009cca
Problem: As soon as I try to fix that with (edit: actually it needs 2 patches)
diff --git a/pkgs/development/libraries/kerberos/krb5.nix b/pkgs/development/libraries/kerberos/krb5.nix
index 42965c0ad07..8ec04e313f9 100644
--- a/pkgs/development/libraries/kerberos/krb5.nix
+++ b/pkgs/development/libraries/kerberos/krb5.nix
@@ -1,4 +1,5 @@
{ stdenv, fetchurl, pkgconfig, perl, yacc, bootstrap_cmds
+, fetchpatch
, openssl, openldap, libedit, keyutils
# Extra Arguments
@@ -22,6 +23,14 @@ stdenv.mkDerivation rec {
sha256 = "121c5xsy3x0i4wdkrpw62yhvji6virbh6n30ypazkp0isws3k4bk";
};
+ patches = [
+ (fetchpatch {
+ url = "https://github.com/krb5/krb5/commit/b009cca2026b615ef5386faa4c0230bc27c4161d.patch";
+ name = "krb5-Fix-typo-in-musl-build-fix.patch";
+ sha256 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
+ })
+ ];
+
outputs = [ "out" "dev" ];
configureFlags = [ "--with-tcl=no" "--localstatedir=/var/lib"]
I get error: infinite recursion encountered, at undefined position
again.
Perhaps the fix of https://github.com/NixOS/nixpkgs/commit/2645e1a1eb41742905394db9d7679a1bb3343eeb just made us lucky by removing something similar to fetchpatch
and using download (curl
?) related things is in fact still broken?
The next nixpkgs master
error is that GHC fails to install (I asked on https://github.com/NixOS/nixpkgs/pull/83164#issuecomment-606958744):
checking whether we are cross compiling... configure: error: in `/build/ghc-8.6.5':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
note: keeping build directory '/tmp/nix-build-ghc-8.6.5.drv-0'
builder for '/nix/store/82xq6ws6si3f7vkycgjsrl76zkjqz7md-ghc-8.6.5.drv' failed with exit code 1
Details from config.log
:
configure:5409: checking for C compiler version
configure:5418: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc --version >&5
gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:5429: $? = 0
configure:5418: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc -v >&5
Using built-in specs.
COLLECT_GCC=/nix/store/axzam0k8kswigp137fwcs9v644k32mf5-gcc-9.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/axzam0k8kswigp137fwcs9v644k32mf5-gcc-9.2.0/libexec/gcc/x86_64-unknown-linux-musl/9.2.0/lto-wrapper
Target: x86_64-unknown-linux-musl
Configured with:
Thread model: posix
gcc version 9.2.0 (GCC)
configure:5429: $? = 0
configure:5418: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:5429: $? = 1
configure:5418: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:5429: $? = 1
configure:5449: checking whether the C compiler works
configure:5471: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc -fuse-ld=gold conftest.c >&5
/nix/store/1aj7gw8zj36rmya0agbrk9wm0w97isdp-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __register_frame_info@GCC_3.0, defined in unused shared library /nix/store/8z497lsggmvgsqjg409s9vmyvjsvys4l-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
/nix/store/1aj7gw8zj36rmya0agbrk9wm0w97isdp-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __deregister_frame_info@GCC_3.0, defined in unused shared library /nix/store/8z497lsggmvgsqjg409s9vmyvjsvys4l-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
configure:5475: $? = 0
configure:5523: result: yes
configure:5526: checking for C compiler default output file name
configure:5528: result: a.out
configure:5534: checking for suffix of executables
configure:5541: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc -o conftest -fuse-ld=gold conftest.c >&5
/nix/store/1aj7gw8zj36rmya0agbrk9wm0w97isdp-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __register_frame_info@GCC_3.0, defined in unused shared library /nix/store/8z497lsggmvgsqjg409s9vmyvjsvys4l-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
/nix/store/1aj7gw8zj36rmya0agbrk9wm0w97isdp-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __deregister_frame_info@GCC_3.0, defined in unused shared library /nix/store/8z497lsggmvgsqjg409s9vmyvjsvys4l-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
configure:5545: $? = 0
configure:5567: result:
configure:5589: checking whether we are cross compiling
configure:5597: /nix/store/mm81kczg6a8wmi2m67adpggsy7wya98a-gcc-wrapper-9.2.0/bin/cc -o conftest -fuse-ld=gold conftest.c >&5
/nix/store/1aj7gw8zj36rmya0agbrk9wm0w97isdp-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __deregister_frame_info@GCC_3.0, defined in unused shared library /nix/store/8z497lsggmvgsqjg409s9vmyvjsvys4l-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
/nix/store/1aj7gw8zj36rmya0agbrk9wm0w97isdp-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __register_frame_info@GCC_3.0, defined in unused shared library /nix/store/8z497lsggmvgsqjg409s9vmyvjsvys4l-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
configure:5601: $? = 0
configure:5608: ./conftest
./configure: line 5610: 2075 Segmentation fault ./conftest$ac_cv_exeext
configure:5612: $? = 139
configure:5619: error: in `/build/ghc-8.6.5':
configure:5621: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
Segmentation fault
in the compiled conftest
program, not good.
@nh2: Also, is there any reason why Hydra's CI does not check that these things build correctly? It seems like it would make your life easier if people couldn't introduce nixpkgs changes that break musl builds
@nh2 Here's the PR where the boot compiler was updated: https://github.com/NixOS/nixpkgs/pull/83048
As far as I know, no one is testing that GHC builds with musl when merging in things like this.
For testing things like this, is there some attribute I can give to ofborg to test stuff like this?
For example, on https://github.com/NixOS/nixpkgs/pull/83048, should I have run something like @grahamcofborg build pkgsMusl.haskell.compilers.ghc865binary
?
@nh2 I've deleted the offending store path, make sure to use Cachix 0.3.7 as it avoids this rare but quite annoying problem :)
Also, is there any reason why Hydra's CI does not check that these things build correctly? It seems like it would make your life easier if people couldn't introduce nixpkgs changes that break musl builds
@Gabriel439 Absolutely, it would make it a lot easier. I guess it would double the amount of building that Hydra would have to do. I imagine in the future we can gather enough musl supporters or infrastructure to make it happen nevertheless.
As far as I know, no one is testing that GHC builds with musl when merging in things like this.
@cdepillabout That's probably right!
For example, on NixOS/nixpkgs#83048, should I have run something like
@grahamcofborg build pkgsMusl.haskell.compilers.ghc865binary
?
I think that would work, yes. The only problem with ofborg is that it limits builds to 3600 seconds or so. So some larger builds may not complete.
What I'd really want would be to hook my community-sponsored builder into the PR/ofborg infrastructure and have it automatically build the relevant musl musl things. But ofborg currently does not support that.
I've deleted the offending store path, make sure to use Cachix 0.3.7 as it avoids this rare but quite annoying problem :)
@domenkozar Thank you!
I'm on 0.3.7 now.
Using a MWE conftest-2.c
of:
#include <stdio.h>
int main() {
FILE *f = fopen("conftest.out", "w");
return ferror(f) || fclose(f) != 0;
}
Compiling with /nix/store/vmg52dd5bdjz8syv73irk4isdyj30x82-gcc-wrapper-9.2.0/bin/cc -fuse-ld=gold -o conftest-2 conftest-2.c
prints:
/nix/store/wx62gczhyd5igi8qi63v6l3jnch120x2-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __deregister_frame_info@GCC_3.0, defined in unused shared library /nix/store/fjq3pkc8hllw4h8jfwhc50w3cf5yyd15-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
/nix/store/wx62gczhyd5igi8qi63v6l3jnch120x2-binutils-2.31.1/bin/ld.gold: warning: discarding version information for __register_frame_info@GCC_3.0, defined in unused shared library /nix/store/fjq3pkc8hllw4h8jfwhc50w3cf5yyd15-gcc-9.2.0-lib/lib/libgcc_s.so.1 (linked with --as-needed)
cc
wrapper)And running ./conftest-2
segfaults. Digging in with edb-debugger, ./conftest-2
& /nix/store/yk5jbq48znw9vvd87kkjvxn5rr69j164-musl-1.1.24/lib/libc.so
are loaded into memory, and execution flows from conftest-2!_start
, to conftest-2!_start_c
, to conftest-2!__libc_start_main@plt
, to conftest-2!frame_dummy
, to conftest-2!__register_frame_info@plt
, to conftest-2!frame_dummy
, at which point there's the following state:
------------------------------------------------------------------------------
rax:00000000004005c0 rcx:0000000000000000 rdx:0000000000400580 rbx:00007f5fcff798c0 rflags:0000000000000206
rsp:00007ffe10fbffe8 rbp:00007ffe10fbfff0 rsi:0000000000402060 rdi:0000000000400818 rip:00000000004005c0
r8:0000000000400801 r9:0000000000000000 r10:00007f5fcff61ae0 r11:00007f5fcff79b60 o d I t s z a P c
r12:000000000040076d r13:00007f5fcff79aa0 r14:00000000000046de r15:0000000000000000
es:0000 cs:0033 ss:002b ds:0000 fs:0000 gs:0000
[002b:00007ffe10fbffe8]---------------------------------------------------------[stack]
00007ffe10fbffe8 : 5d 07 40 00 00 00 00 00 - 48 9a f7 cf 5f 7f 00 00 ].@.....H..._...
00007ffe10fbfff8 : 86 05 40 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ..@.............
00007ffe10fc0008 : 22 a6 f2 cf 5f 7f 00 00 - 00 00 00 00 00 00 00 00 "..._...........
00007ffe10fc0018 : 00 00 00 00 00 00 00 00 - 7e 3c b0 20 00 00 00 00 ........~<. ....
[0000:0000000000400000]---------------------------------------------------------[ data]
0000000000400000 : 7f 45 4c 46 02 01 01 00 - 00 00 00 00 00 00 00 00 .ELF............
0000000000400010 : 02 00 3e 00 01 00 00 00 - 00 06 40 00 00 00 00 00 ..>.......@.....
[0033:00000000004005c0]---------------------------------------------------------[ code]
> 00000000004005c0: jmp qword [rel 0x402010]
00000000004005c6: push 2
00000000004005cb: jmp 0x400590
00000000004005d0: jmp qword [rel 0x402018]
00000000004005d6: push 3
00000000004005db: jmp 0x400590
------------------------------------------------------------------------------
It's about to jump to 0x402010
, which is inside the rw-
memory range (not the r-x
range) for conftest-2
.
That section of memory:
00000000:00402010|00 00 00 00 00 00 00 00 38 9e f1 cf 5f 7f 00 00|........8..._...|
Attempting to execute this instruction gives the following state:
------------------------------------------------------------------------------
rax:00000000004005c0 rcx:0000000000000000 rdx:0000000000400580 rbx:00007f5fcff798c0 rflags:0000000000000206
rsp:00007ffe10fbffe8 rbp:00007ffe10fbfff0 rsi:0000000000402060 rdi:0000000000400818 rip:0000000000000000
r8:0000000000400801 r9:0000000000000000 r10:00007f5fcff61ae0 r11:00007f5fcff79b60 o d I t s z a P c
r12:000000000040076d r13:00007f5fcff79aa0 r14:00000000000046de r15:0000000000000000
es:0000 cs:0033 ss:002b ds:0000 fs:0000 gs:0000
[002b:00007ffe10fbffe8]---------------------------------------------------------[stack]
00007ffe10fbffe8 : 5d 07 40 00 00 00 00 00 - 48 9a f7 cf 5f 7f 00 00 ].@.....H..._...
00007ffe10fbfff8 : 86 05 40 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ..@.............
00007ffe10fc0008 : 22 a6 f2 cf 5f 7f 00 00 - 00 00 00 00 00 00 00 00 "..._...........
00007ffe10fc0018 : 00 00 00 00 00 00 00 00 - 7e 3c b0 20 00 00 00 00 ........~<. ....
[0000:0000000000402010]---------------------------------------------------------[ data]
0000000000402010 : 00 00 00 00 00 00 00 00 - 38 9e f1 cf 5f 7f 00 00 ........8..._...
0000000000402020 : 68 93 f1 cf 5f 7f 00 00 - a0 92 f1 cf 5f 7f 00 00 h..._......._...
[0033:0000000000000000]---------------------------------------------------------[ code]
------------------------------------------------------------------------------
And stepping once more segmentation faults.
NixOS/nixpkgs#49071 might be our issue here?
After chasing issues down, it looks like NixOS/nixpkgs#84741 fixed this problem, and applying NixOS/nixpkgs@acfccf7f5ba83ce4ec279ce4416e5de5edca2fb7 to nixos-20.03
lets GHC build properly.
Cloning Aura & running nix-build ./nix -A staticProject.static_package
will give you a successful static build using nixos-20.03
, Stack 2.1, and Stackage lts-15.13. Not sure how to go about upstreaming all the patches in there to make those play. (At least the Nixpkgs patch shouldn't be necessary on nixos-unstable
(as the merged commit, https://github.com/NixOS/nixpkgs/commit/4675649d9cd06d13f8f127855dda4993881dd81b, is present.)
Here's the reproduction:
Here's the evaluation failure:
I believe this is not the same thing as #9 since that is a build failure whereas this is an evaluation failure.