!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

230 Members
75 Servers

Load older messages

SenderMessageTime
11 Nov 2024
@reckenrode:matrix.orgRandy Eckenrode
In reply to @emilazy:matrix.org
I think this is the idea, yes

I tried reverting the NIX_DONT_SET_RPATH_FOR_TARGET change. It didn’t seem to make a difference.

23:27:03
@emilazy:matrix.orgemily
In reply to @reckenrode:matrix.org
preHook = preHook + lib.optionalString buildPlatform.isDarwin ''
  export NIX_DONT_SET_RPATH_FOR_BUILD=1
'' + lib.optionalString (hostPlatform.isDarwin || (!hostPlatform.isElf && !hostPlatform.isMacho)) ''
  export NIX_DONT_SET_RPATH=1
  export NIX_NO_SELF_RPATH=1
'' + lib.optionalString (hostPlatform.isDarwin && hostPlatform.isMacOS) ''
  export MACOSX_DEPLOYMENT_TARGET=${hostPlatform.darwinMinVersion}
'' + lib.optionalString targetPlatform.isDarwin ''
  export NIX_DONT_SET_RPATH_FOR_TARGET=1
'';
honestly, just replacing all of that with NIX_DONT_SET_RPATH_aarch64_apple_darwin/NIX_DONT_SET_RPATH_x86_64_apple_darwin seems cool to me 		23:27:14
@emilazy:matrix.orgemily
In reply to @reckenrode:matrix.org

I tried reverting the NIX_DONT_SET_RPATH_FOR_TARGET change. It didn’t seem to make a difference.

there's the nostdlibinc patch 		23:27:24
@emilazy:matrix.orgemilytry removing it entirely23:27:32
@reckenrode:matrix.orgRandy Eckenrode
In reply to @emilazy:matrix.org
honestly, just replacing all of that with NIX_DONT_SET_RPATH_aarch64_apple_darwin/NIX_DONT_SET_RPATH_x86_64_apple_darwin seems cool to me
It’s exposing a cc-wrapper internal detail, which is also different on static Darwin builds. 		23:27:38
@reckenrode:matrix.orgRandy Eckenrode
In reply to @emilazy:matrix.org
try removing it entirely
Doesn’t matter either. 		23:28:47
@reckenrode:matrix.orgRandy Eckenrode
In reply to @emilazy:matrix.org
try removing it entirely
* 		23:28:54
@reckenrode:matrix.orgRandy Eckenrode

Does every clang dependency have to be audited for targetPlatform stuff?

23:29:59
@reckenrode:matrix.orgRandy Eckenrode

Note that this includes my “Darwin as useLLVM” work.

23:30:30
@emilazy:matrix.orgemily well, ideally targetPlatform would be null so they would have no way of depending on it 23:30:58
@emilazy:matrix.orgemily I'm curious what nix-diff says though 23:31:09
@reckenrode:matrix.orgRandy Eckenrode

Output of nix-diff $(nix-instantiate . -A clang.cc) $(nix-instantiate . -A pkgsCross.gnu64.buildPackages.clang.cc) with the NIX_DONT_SET_RPATH_FOR_TARGET change reverted and the -nostdlibinc patches dropped.

https://gist.github.com/reckenrode/be122136283d8ed5a05d52f2f57d8809

23:41:53
@emilazy:matrix.orgemilythe bootstrap stuff seems solvable23:43:15
@emilazy:matrix.orgemily if we used the earlier stage compilers to bootstrap pkgsCross 23:43:26
@emilazy:matrix.orgemily I think comparing two pkgsCrosses would be more enlightening though 23:43:39
@emilazy:matrix.orgemilysince that's still significantly more sharing23:43:42
@emilazy:matrix.orgemilyand would eliminate that difference23:43:47
@emilazy:matrix.orgemily like gnu64 and aarch64-multiplatform instead 23:43:56
@emilazy:matrix.orgemily (or I guess aarch64-multiplatform and however x86_64-darwin is spelled, to capture OS differences) 23:45:44
12 Nov 2024
@reckenrode:matrix.orgRandy EckenrodeI can check in a bit.00:55:17
@sternenseemann:systemli.orgsterni emily: mainly the LLVM LLVMGold.so thing depending on GNU binutils or not, could be interesting to remove that somehow 12:18:23
@sternenseemann:systemli.orgsterniI think sharing between normal clang and cross clang is a bigger win though12:18:43
@sternenseemann:systemli.orgsterni Ideally you can just pass useLLVM and never need to rebuild anything big 12:19:06
@sternenseemann:systemli.orgsterni
In reply to @emilazy:matrix.org
well, ideally targetPlatform would be null so they would have no way of depending on it
that doesn't make sense, you always have a target platform in a package set and Nix can figure out whether it needs rebuilding or not on its own 		12:19:58
@sternenseemann:systemli.orgsterni subtle problems are usually introduced elsewhere, so nulling it for some derivations isn't really solving anything 12:20:45
@sternenseemann:systemli.orgsterni if you care about it, just add a test somewhere that comparse outPaths i'd say 12:21:04
@sternenseemann:systemli.orgsterni
In reply to @sternenseemann:systemli.org
emily: mainly the LLVM LLVMGold.so thing depending on GNU binutils or not, could be interesting to remove that somehow
i.e. would be nice if this could be outside the LLVM derivation 		12:21:31
@emilazy:matrix.orgemily
In reply to @sternenseemann:systemli.org
subtle problems are usually introduced elsewhere, so nulling it for some derivations isn't really solving anything
the really nice thing about nulling it is that it allows dependency specification that people can actually make sense of https://github.com/NixOS/nixpkgs/issues/227327 		13:35:10
@p14:matrix.orgp14
In reply to @sternenseemann:systemli.org
emily: mainly the LLVM LLVMGold.so thing depending on GNU binutils or not, could be interesting to remove that somehow
I had noticed this one too. AFAIU, the interface it uses is stable, so shouldn’t very much in theory. I don’t know how that holds in practice. If you are building with a useLLVM tool chain with the LLD linker, then it is redundant anyway. Maybe the dependency could be dropped in that case at least? 		15:06:39
@sternenseemann:systemli.orgsterniI think it needs to link against libbfd (would need to verify), so it depends on whether it is available for a given target since binutils is not target agnostic17:10:51

Show newer messages

Back to Room ListRoom Version: 9