Closed OPNA2608 closed 2 years ago
The problem seems to be that cc
was added to makeBinaryWrapper
's deps
in https://github.com/NixOS/nixpkgs/pull/150079. Removing it makes your reproducer give the expected output.
It was apparently added to fix issues on aarch64-darwin, though the error logs are gone. I'll try to reproduce the errors in a test PR.
EDIT:
libc++abi: terminating with uncaught exception of type std::runtime_error: Failed to spawn codesign_allocate: No such file or directory
/nix/store/0zrljp1ph80sz8qdr27w4cc4s8dphbas-post-link-sign-hook: line 2: 84994 Abort trap: 6 CODESIGN_ALLOCATE=codesign_allocate /nix/store/wa5xzmvj3a1hg751p9dicy6jgalbbjc3-sigtool-0.1.2/bin/codesign -f -s - "$linkerOutput"
collect2: error: ld returned 134 exit status
ping @bergkvist
Seems like we're hitting https://github.com/NixOS/nixpkgs/issues/148189. Maybe we can add cc
or cctools
to deps
only on aarch64-darwin for the time being.
I remember I was stuck on that codesign_allocate error for some time while working on the fix for aarch64-darwin - and that adding cc to deps made the error go away. I don't think I dug much deeper into the underlying cause after that.
Based on my tests, adding cctools
to deps
on aarch64-darwin is enough to make the tests pass. Hopefully that's acceptable regarding the current issue.
I'll make a PR soon. EDIT: https://github.com/NixOS/nixpkgs/pull/172366
Note that this had to be unfixed on aarch64-darwin for now: https://github.com/NixOS/nixpkgs/pull/174038
Describe the bug
Summary:
Including
wrapGAppsHook
in thenativeBuildInputs
of a derivation X that uses a non-standard stdenv (i.e.stdenv = gcc10Stdenv;
) taints derivation X's environment with the compiler that is used by (presumably)makeBinaryWrapper
, causing the wrong compiler to get used by the build.Hit this while trying to unbreak
palemoon
. Our default compiler right now is GCC11, which the packaged version of Pale Moon doesn't support.(For slightly complicated reasons, the Pale Moon version we have packaged isn't technically the latest version some of the online docs assume, but it is the recommended one. We could bump the package, but I'd rather wait until the next good version is released. See #165221 for more details.)
Since the packaged version is only compatible with up to GCC10, I tried to change the
all-packages.nix
entry toThis makes the Nix-level asserts pass (which check
stdenv.cc.version
for license compliance reasons), but the compiler the build actually ends up using is GCC11, which leads to a failed build.Turns out that the culprit is
wrapGAppsHook
which seems to insert its GCC before the desired stdenv's GCC.which -a gcc
insidepalemoon
'spostPatch
returns:Steps To Reproduce
A minimal reproducer (on a checkout of eb935d1294340b14eb3f33dac547e15df5801b3b):
Yields the expected output.
Uncommenting the
nativeBuildInputs
yields:I'll push an expected-to-work PR for
palemoon
shortly, which would be a more complicated reproducer of this.Expected behavior
Builds should use the compiler they are told to use.
Screenshots
Additional context
It looks like
wrapGAppsHook
was recently migrated to the newmakeBinaryWrapper
via #164163. That seems like the most likely culprit to me.Notify maintainers
CC @ncfavier (author of #164163)
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.