radicle-upstream: workaround build failure due to missing libgcc #250710
Conversation
Without the change build fails as:
> searching for dependencies of /nix/store/gv5yvdd91vg3f4s1j6zf07xkclcpqn1c-git-remote-rad-0.3.0/bin/git-remote-rad
> libgcc_s.so.1 -> not found!
> auto-patchelf: 1 dependencies could not be satisfied
This happens because `autoPatchelfHook` does not pull the dependency in
automatically and requires explicitly exposing internal implementation
details of the `stdenv`.
ofborg
bot
added
10.rebuild-darwin: 0
10.rebuild-linux: 1-10
10.rebuild-linux: 1
labels
| @@ -25,7 +25,7 @@ let | |||
| src = contents; | |||
|
|
|||
| nativeBuildInputs = [ autoPatchelfHook ]; | |||
| buildInputs = [ zlib ]; | |||
| buildInputs = [ zlib stdenv.cc.cc.libgcc or null ]; | |||
There was a problem hiding this comment.
Please add parens for clarity. I'm surprised that even evals.
I think something along the lines of ++ optionals stdenv.cc.isGNU [ stdenv.cc.cc.libgcc ] would be cleaner and easier to read.
A comment explaining why it needs this would also be nice.
Also why is it cc.cc? Not very knowledgable about stdenv.
There was a problem hiding this comment.
Please add parens for clarity. I'm surprised that even evals.
I took stdenv.cc.cc.libgcc or null as is from one of those:
$ git grep -F 'stdenv.cc.cc.libgcc or null' | cat
pkgs/development/interpreters/python/pypy/prebuilt.nix: stdenv.cc.cc.libgcc or null
pkgs/development/interpreters/python/pypy/prebuilt_2_7.nix: stdenv.cc.cc.libgcc or null
pkgs/development/mobile/androidenv/tools.nix: stdenv.cc.cc.libgcc or null # fix for https://github.com/NixOS/nixpkgs/issues/226357
pkgs/tools/admin/pulumi-bin/default.nix: buildInputs = [ stdenv.cc.cc.libgcc or null ];
pkgs/tools/admin/realvnc-vnc-viewer/linux.nix: buildInputs = [ libX11 libXext stdenv.cc.cc.libgcc or null ];
pkgs/top-level/all-packages.nix: libgcc = stdenv.cc.cc.libgcc or null;
I agree it's confusing, but I though it's at least consistent.
I think something along the lines of ++ optionals stdenv.cc.isGNU [ stdenv.cc.cc.libgcc ] would be cleaner and easier to read.
I'm not sure if stdenv.cc.cc.libgcc is present in pkgsStatic (or expected to be present).
A comment explaining why it needs this would also be nice. Also why is it cc.cc? Not very knowledgable about stdenv.
Good question. I'm probably the worst person to defend the solution. I filed #250744 instead and added a note on the PR that caused the regression: #209870 (comment)
There was a problem hiding this comment.
I'm not sure if
stdenv.cc.cc.libgccis present inpkgsStatic(or expected to be present).
It isn't. pkgsStatic is one the common reasons for the or null.
dlopen() has always been an unsolved problem for autoPatchelfHook.
|
Closing in favour #250744 issue. |
Without the change build fails as:
This happens because
autoPatchelfHookdoes not pull the dependency in automatically and requires explicitly exposing internal implementation details of thestdenv.Description of changes
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/)