!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

265 Members
81 Servers

Load older messages

SenderMessageTime
3 Sep 2023
@p14:matrix.orgp14Is there any testing machinery someone can run #253116 through, is it possible to have a hydra job for it?12:57:51
@artturin:matrix.orgArtturin Running nix build -f tests.cc-wrapper 13:07:16
@artturin:matrix.orgArtturin* Im running nix build -f tests.cc-wrapper13:07:48
@artturin:matrix.orgArtturin* Im running `nix build -f tests.cc-wrapper`13:07:59
@artturin:matrix.orgArtturinit built14:28:22
@p14:matrix.orgp14Artturin: What next? Any opinion as to whether it may go into staging?14:31:08
@p14:matrix.orgp14
In reply to @p14:matrix.org
Artturin: I also tried building pkgsStatic.pkgsLLVM.clang.cc -- for this I hit the error message you described in https://github.com/NixOS/nixpkgs/issues/22060 ( file RPATH_CHANGE could not write new RPATH:) while in the ninja install phase of llvm.
For this it seems I want to set -DCMAKE_SKIP_INSTALL_RPATH=On to avoid the cmake error. Would it make sense to inhibit this in general with the static build stdenv adaptor? 		15:29:31
@p14:matrix.orgp14 Hmm, it's not clear where to put such logic. Essentially "if we're building static binaries, we don't have an rpath and we don't want cmake to do rpath manipulation". Feels like it could go into makeStaticBinaries. 15:37:36
@p14:matrix.orgp14Success, I was able to build pkgsStatic.pkgsLLVM.clang.cc, and it also appears to work.15:58:26
@p14:matrix.orgp14

Needed this to fix cmake builds though, does it seem reasonable?

diff --git a/pkgs/stdenv/adapters.nix b/pkgs/stdenv/adapters.nix
index f29bdf671c8c..dbc80e6bfbe0 100644
--- a/pkgs/stdenv/adapters.nix
+++ b/pkgs/stdenv/adapters.nix
@@ -64,8 +64,9 @@ rec {
         configureFlags = (finalAttrs.configureFlags or []) ++ [
-            "--disable-shared" # brrr...
-          ];
+          "--disable-shared" # brrr...
+        ];
+        cmakeFlags = (finalAttrs.cmakeFlags or []) ++ ["-DCMAKE_SKIP_INSTALL_RPATH=On"];
       }));
     } // lib.optionalAttrs (stdenv0.hostPlatform.libc == "glibc") {
15:59:30
@artturin:matrix.orgArtturin
In reply to @p14:matrix.org

Needed this to fix cmake builds though, does it seem reasonable?

diff --git a/pkgs/stdenv/adapters.nix b/pkgs/stdenv/adapters.nix
index f29bdf671c8c..dbc80e6bfbe0 100644
--- a/pkgs/stdenv/adapters.nix
+++ b/pkgs/stdenv/adapters.nix
@@ -64,8 +64,9 @@ rec {
         configureFlags = (finalAttrs.configureFlags or []) ++ [
-            "--disable-shared" # brrr...
-          ];
+          "--disable-shared" # brrr...
+        ];
+        cmakeFlags = (finalAttrs.cmakeFlags or []) ++ ["-DCMAKE_SKIP_INSTALL_RPATH=On"];
       }));
     } // lib.optionalAttrs (stdenv0.hostPlatform.libc == "glibc") {
superficially ok but put it in a separate PR 		16:11:25
@artturin:matrix.orgArtturin
In reply to @p14:matrix.org
Artturin: What next? Any opinion as to whether it may go into staging?
wait a few days for comments 		16:11:44
@artturin:matrix.orgArtturin
In reply to @p14:matrix.org
Artturin: What next? Any opinion as to whether it may go into staging?
* wait a few days for reviews 		16:11:47
@p14:matrix.orgp14
In reply to @artturin:matrix.org
superficially ok but put it in a separate PR
Is that one (the makeStaticBinaries change) for staging or master do you think? 		16:19:01
@artturin:matrix.orgArtturin
In reply to @p14:matrix.org
Is that one (the makeStaticBinaries change) for staging or master do you think?
ofborg will probably show <500 rebuilds but it'll rebuild everything pkgsStatic so do staging 		16:56:58
@p14:matrix.orgp14 I'm a little confused. I'm looking at makeStaticBinaries, and I see you can turn off via finalAttrs.dontAddStaticConfigureFlags. However, when I do thePackage.overrideAttrs (final: prev: { dontAddStaticConfigureFlags = true; } it doesn't appear to have the desired effect of disabling the --disable-shared configure flag. 16:58:10
@p14:matrix.orgp14 A cursory test by eval'ing foo.thing in foo = ((self.stdenv.mkDerivation { name = "foo"; src = ""; val = "a"; }).overrideAttrs (final: prev: { thing = final.val; })).overrideAttrs (final: prev: { val = "b"; }); seems to suggest that I should be able to add an overrideAttrs to influence this 16:59:08
@artturin:matrix.orgArtturindontAddStaticConfigureFlags is to stdenv instead of the derivatin16:59:12
@artturin:matrix.orgArtturin * dontAddStaticConfigureFlags is to stdenv instead of the derivation16:59:16
@p14:matrix.orgp14Ahh, thanks16:59:19
@artturin:matrix.orgArtturinbut there are uses of it in packages and in the manual :?17:00:23
@p14:matrix.orgp14 I don't quite get it; I see (mkDerivationSuper args).overrideAttrs (finalAttrs: ..) suggesting that it is applying it to the derivation (the output of mkDerivationSuper). 17:00:38
@artturin:matrix.orgArtturinone argument to overrideAttrs is previousAttrs not finalAttrs17:04:56
@artturin:matrix.orgArtturinmight be the issue17:05:04
@p14:matrix.orgp14aha, nice and confusing :)17:05:11
@p14:matrix.orgp14simple bug to fix then?17:05:16
@p14:matrix.orgp14(introduce prevAttrs)17:05:19
@p14:matrix.orgp14[i'll see about testing shortly]17:05:47
@p14:matrix.orgp14

Ah, darn, that hits the infinite recursion with the comment (following); so I guess the 'bug' here is merely that I was mislead by it being called finalAttrs.

# An infinite recursion here can be caused by having the attribute names of expression ein.overrideAttrs(finalAttrs: previousAttrs: e)depend onfinalAttrs. Only the attribute values of ecan depend onfinalAttrs.

17:10:51
@p14:matrix.orgp14.. and it also looks impervious to being overridden via an overlay so I'll have to override configureFlags directly instead to filter out the unwanted args.17:12:51

Show newer messages

Back to Room ListRoom Version: 9