llvmPackages.libc: fix infinite recursion#375330
llvmPackages.libc: fix infinite recursion#375330RossComputerGuy wants to merge 2 commits intoNixOS:masterfrom
Conversation
|
How to reproduce the failure? |
Very reproducible in |
|
This PR + #365057 and this patch applied has the effect of fixing the problem: diff --git a/pkgs/development/libraries/openssl/default.nix b/pkgs/development/libraries/openssl/default.nix
index f6022fb2258a..96babb27e2b1 100644
--- a/pkgs/development/libraries/openssl/default.nix
+++ b/pkgs/development/libraries/openssl/default.nix
@@ -99,7 +99,7 @@ let
setOutputFlags = false;
separateDebugInfo =
# Using "cc.isClang" causes infinite recursion.
- !stdenv.hostPlatform.isDarwin && stdenv.hostPlatform.cc != "clang" && stdenv.cc.isGNU;
+ !stdenv.hostPlatform.isDarwin && stdenv.hostPlatform.cc != "clang" && stdenv.hostPlatform.cc != "gcc";
nativeBuildInputs =
lib.optional (!stdenv.hostPlatform.isWindows) makeBinaryWrapper
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index e8d96d53214a..e429b6730338 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -9051,18 +9051,18 @@ with pkgs;
glibcLocales =
if stdenv.hostPlatform.isLinux && stdenv.hostPlatform.isGnu
then callPackage ../development/libraries/glibc/locales.nix {
- stdenv = if (!stdenv.cc.isGNU) then
+ stdenv = if (stdenv.hostPlatform.cc != "gcc") then
gccStdenv
else stdenv;
- withLinuxHeaders = !stdenv.cc.isGNU;
+ withLinuxHeaders = stdenv.hostPlatform.cc != "gcc";
} else null;
glibcLocalesUtf8 =
if stdenv.hostPlatform.isLinux && stdenv.hostPlatform.isGnu
then callPackage ../development/libraries/glibc/locales.nix {
- stdenv = if (!stdenv.cc.isGNU) then
+ stdenv = if (stdenv.hostPlatform.cc != "gcc") then
gccStdenv
else stdenv;
- withLinuxHeaders = !stdenv.cc.isGNU;
+ withLinuxHeaders = stdenv.hostPlatform.cc != "gcc";
allLocales = false;
} else null; |
Is all of this actually able to be merged soon? If not I'd rather revert the original PR breakage so I can turn the update bot back on. |
I'm expecting it to be soon, there's been discussions on Matrix on further action which I did complete just like an hour ago. Just need reviews. |
|
It seems like #381065 was supposed to work around this, but Is there a real fix anywhere in sight? I'd really like to use the rebuild-amount script again. |
|
What's the stack trace? That PR worked around it so |
Here it is: Details |
|
@RossComputerGuy When is this going to be fixed? If it isn't fixed soon I think it would be appropriate to revert the commits that caused the breakage. |
fd84c90 to
26840df
Compare
|
I came up with a hacky solution |
26840df to
cdf4660
Compare
There is no description in the commit message, no comments. It's not possible to tell why removing the IIUC, the breakage has been caused by adding the |
Is |
|
CC @NixOS/llvm so the rest of the LLVM team looks at this.
Random failures are not likely to come up. The problems are mostly regarding the build dependencies, like expat and CMake. I could try finding a better solution but this is what I was able to come up with.
Yeah though I don't want to remove
Yes and no. It's very useful for trying to see how an LLVM libc stdenv works.
This is something @alyssais and I agreed upon. We shouldn't be conflating a libc and a toolchain. |
I can see how you don't want to conflate those in settings like But at the "top-level package set" level? It really makes no sense to expose something that is not useful to many. Those package sets don't enable any functionality, they are just a shorthand for those who don't (want to) know about the details.
You could still achieve the same with a manual override for Edit: Additionally, there comes a certain degree of "support" with defining a top-level package set. The support level is tiny, of course, but making this a top-level package set at least indicates, that someone cared about making this thing work in principle at some point in time. Which seems not to be the case for an "experiment" like this, where the actual goal (IIUC) is to make |
|
To move this forward I've opened a PR to revert. #401317 I don't care which PR is merged but I do want this breakage fixed. |
|
I don’t have time to review this for 25.05, but copying initial impressions from #401317 (comment):
|
That's fine, I just will need it eventually to help with more LLVM libc development upstream. |
ecf711e to
389f92b
Compare
|
Rebased + redid the way the infinite recursion was worked around. Now it shouldn't break every time someone adds something to python. |
389f92b to
c17b370
Compare
0a1ace9 to
4350497
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
4350497 to
b92a9d0
Compare
b92a9d0 to
5ac9d97
Compare
|
Fixed conflicts, again |
5ac9d97 to
73e6b02
Compare
Things done
Fix nix-community/infra#1676, still need to fix which comes from curl which comes from cmake:
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.