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

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.

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.

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.

In reply to @trofi:matrix.org
(like abandoned https://github.com/NixOS/nixpkgs/pull/181724)