It would also fix the following warnings when SwiftPM invokes Clang.

Warning: supplying the --target arm64-apple-macosx10.13 != arm64-apple-darwin argument to a nix-wrapped compiler may not work correctly - cc-wrapper is currently not designed with multi-target compilers in mind. You may want to use an un-wrapped compiler instead.

It would also fix the following warnings when SwiftPM invokes Clang.

clang: warning: overriding '-mmacos-version-min=11.3' option with '-target arm64-apple-macosx10.13'

Randy Eckenrode: Hey there, Darwin question for you. ponyc does this and we have to patch:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/po/ponyc/fix-darwin-build.patch

However, hydra is complaining about:

ld: warning: directory not found for option '-L/nix/store/6fg11q5s4xpgfpvps1hy7w9vjhfl14mx-Libsystem-11.0/lib'
ld: library not found for -lSystem

Feel like I'm just missing something stupid here.

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

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

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

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.