Nixpkgs Stdenv - Public Room Timeline - Matrix Static

	Nixpkgs Stdenv	252 Members
		78 Servers

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

Sender	Message	Time
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	Ideally wrappers should always expose prefixed binaries.	14:34:59
trofi	(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	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

Show newer messages

Back to Room ListRoom Version: 9