Skip to content

radicle-upstream: workaround build failure due to missing libgcc #250710

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
trofi wants to merge 1 commit into from
Closed

radicle-upstream: workaround build failure due to missing libgcc #250710

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion pkgs/applications/version-management/radicle-upstream/default.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ let
src = contents;

nativeBuildInputs = [ autoPatchelfHook ];
buildInputs = [ zlib ];
buildInputs = [ zlib stdenv.cc.cc.libgcc or null ];
Copy link
Member

@Atemu Atemu Aug 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@trofi trofi Aug 22, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

@vcunat vcunat Aug 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NixOS/nix#629

Copy link

@ghost ghost Aug 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if stdenv.cc.cc.libgcc is present in pkgsStatic (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.


installPhase = ''
mkdir -p $out/bin/
Expand Down