Nixpkgs Stdenv - Public Room Timeline

	Nixpkgs Stdenv	214 Members
		69 Servers

You have reached the beginning of time (for this room).

Sender	Message	Time
9 May 2025
p14	Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But NIX_LDFLAGS_AFTER_@suffixSalt@ is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:01:05
p14	* Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But `NIX\_LDFLAGS\_AFTER\_@suffixSalt@` is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:01:27
p14	* Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But `NIX_LDFLAGS_AFTER_@suffixSalt@` is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:01:35
p14	It looks to me like the second condition (`$linkType` == dynamic) doesn't especially make sense to be gated by `if [ -z "${NIX_LINK_TYPE_@suffixSalt@:-}" ]`, so it doesn't belong nested in that conditional. And I don't see a good reason to gate the availability of 'NIX_LDFLAGS_*` on the link type.	06:03:34
p14	* Wait, does this make sense? https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L84-L95 `NIX_LDFLAGS_@suffixSalt@` and `NIX_LDFLAGS_BEFORE_@suffixSalt@` are gated on the link type being empty. But `NIX_LDFLAGS_AFTER_@suffixSalt@` is not. An oversight, I presume? I just hit it with a bit of confusion as to why my override was not having effect in a static build (where the link type is set to static, but $NIX_LINK_TYPE is empty). It also looks to me like any tests should be using $linkType, per https://github.com/NixOS/nixpkgs/blob/907e98d6cc08e3261b63e3f8d2831841817b0041/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L32	06:04:24
p14	Oh, meanwhile, NIX_LDFLAGS_BEFORE are also handled in the cc-wrapper, and added as -Wl, to add to the confusion. And the actual reason my flags weren't taking effect was because I had the wrong suffixSalt in effect.	06:17:29
10 May 2025
p14	I'm messing with my own stdenvStages as an experiment and to learn about the stdenv. I've hit upon a fun problem. If I add my own stage which makes use of a suffixed compiler from an earlier stage, the wrapped compiler is suffixed but the unwrapped compiler is not. This line: https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L93 Ends up putting the $CC_FOR_BUILD's unwrapped compiler in the $PATH before the host compiler. So `which $CC` resolves as the unwrapped $CC_FOR_BUILD instead of $CC's wrapped compiler. This works fine for most standard scenarios, I think, because normally you'd be using some native (and unsuffixed) compiler as $CC_FOR_BUILD (=gcc) and the $CC would be set to some suffixed compiler. So if `$PATH = cc-for-build:cc-for-build-unwrapped:cc:cc-unwrapped`; the path search works fine because it find the suffixed compiler in `:cc:`. Not sure exactly how to solve it; I don't yet see why you'd want the unwrapped compiler in the path at all.	12:05:51
p14	* I'm messing with my own stdenvStages as an experiment and to learn about the stdenv. I've hit upon a fun problem. If I add my own stage which makes use of a suffixed compiler from an earlier stage, the wrapped compiler is suffixed but the unwrapped compiler is not. This line: https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L93 Ends up putting the $CC_FOR_BUILD's unwrapped compiler in the $PATH before the host compiler. So `which $CC` resolves as the unwrapped $CC_FOR_BUILD instead of $CC's wrapped compiler. This works fine for most standard scenarios, I think, because normally you'd be using some native (and unsuffixed) compiler as $CC_FOR_BUILD (=gcc) and the $CC would be set to some suffixed compiler. So if `$PATH = cc-for-build:cc-for-build-unwrapped:cc:cc-unwrapped`; the path search works fine because it finds the suffixed compiler in `:cc:`. Not sure exactly how to solve it; I don't yet see why you'd want the unwrapped compiler in the path at all.	12:06:16
p14	* I'm messing with my own stdenvStages as an experiment and to learn about the stdenv. I've hit upon a fun problem. If I add my own stage which makes use of a target-prefixed compiler from an earlier stage, the wrapped compiler is prefixed but the unwrapped compiler is not. This line: https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L93 Ends up putting the $CC_FOR_BUILD's unwrapped compiler in the $PATH before the host compiler. So `which $CC` resolves as the unwrapped $CC_FOR_BUILD instead of $CC's wrapped compiler. This works fine for most standard scenarios, I think, because normally you'd be using some native (and unprefixed) compiler as $CC_FOR_BUILD (=gcc) and the $CC would be set to some prefixed compiler. So if `$PATH = cc-for-build:cc-for-build-unwrapped:cc:cc-unwrapped`; the path search works fine because it finds the prefixed compiler in `:cc:`. Not sure exactly how to solve it; I don't yet see why you'd want the unwrapped compiler in the path at all.	12:12:50
11 May 2025
@trofi:matrix.org	Ideally wrappers should always expose prefixed binaries.	14:34:59
@trofi:matrix.org	(like abandoned https://github.com/NixOS/nixpkgs/pull/181724)	14:35:49
Tristan Ross	In reply to @trofi:matrix.org (like abandoned https://github.com/NixOS/nixpkgs/pull/181724) Rip yeah, imo we should be closing abandoned PR's because there's not really a point in leaving them open	15:04:17
Alyssa Ross	Is there a point in closing them?	15:06:07
Tristan Ross	Well if it's not going to be worked on anytime soon, why leave like a 2yo PR that has merge conflicts open?	15:07:18
emily	it was closed in 2022?	15:07:48
@trofi:matrix.org	looking at the comment it broke meson-based builds on clang (and they used to work by accident by using a wrong compiler)	15:08:53
p14	But is there a good reason to put the unwrapped CC in the path? I have dropped it without ill effect and it does fix things ion my case.	17:17:03
emily	we don't but we do want prefixed compilers	17:18:55
emily	so the prefixed ones should probably be wrapped	17:19:10
p14	So, could https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L92-L94 and https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/bintools-wrapper/setup-hook.sh#L39-L41 be dropped. In light of the commit message here https://github.com/NixOS/nixpkgs/pull/182385/commits/e682dd84cff5d2420fcc0a40508557477f6cc9d3 which comments that it was unknown why there were in the path (but the answer is linked above). Now it is found, can we delete it? :)	18:42:09
p14	I'm thinking that essentially if there is some binary provided by the compiler and it's not symlinked into the wrapper, that is a bug.	18:43:42
p14	While messing with the booting machinery I am hitting an odd thing where somehow a meson is creeping in which has an openmp dependency which creates an infinite cycle. Haven't debugged it yet. (clang -> tblgen -> cmake -> libarchive -> e2fsprogs -> fuse -> meson (from some other stage) -> openmp -> infinite cycle on clang). I guess I need to plug something into my stdenv overrides to prevent this.	18:54:42
@trofi:matrix.org	`e2fsprogs -> fuse` can be broken by disabling `withFuse = false;`	18:56:41
p14	Do you happen to know of any good ways to visualise the dependency graph across the stages? I've resorted to injecting names into derivations to indicate which stage they're in, which helps, but within a stage it can be helpful to understand the why-depends relationships of things without having to manually invoke it repeatedly.	19:03:57
Randy Eckenrode	https://github.com/NixOS/nixpkgs/blob/5d0f68d3c0af3ecd33697bccfba40f73c82526ca/pkgs/stdenv/linux/default.nix#L33-L55	19:12:34
Randy Eckenrode	Should work for any stdenv that follows similar stage naming conventions.	19:12:52
Randy Eckenrode	(I’ve used it when working on Darwin’s.)	19:13:00
@trofi:matrix.org	+1. Yeah, I usually use that with a bit of grep tweaks.	19:25:18
p14	It'd be great if the stdenvs had differing names (I have given mine different names, but I'm also thinking of those appearing by use of overrideCC within llvm common.	20:28:59
Randy Eckenrode	Darwin’s stdenv is `stdenv-darwin`, and its bootstrap stages are suffixed with `-stdenv-darwin`, but they follow the same `bootstrap-stageX` convention that Linux does, so that `grep` works on Darwin.	20:46:32

Show newer messages

Back to Room ListRoom Version: 9