I have not tried this yet, but I can confirm that this is a constant source of annoyance for us because Go crashes anytime we import something that uses C. On my end (at work) I have this snippet which works (copied only relevant parts, but you get the idea):

  # in a let statement
  appleFrameworks = with pkgs.darwin.apple_sdk.frameworks; [
    "-F${CoreFoundation}/Library/Frameworks"
    "-F${CoreServices}/Library/Frameworks"
    "-F${Foundation}/Library/Frameworks"
    "-F${Security}/Library/Frameworks"
  ];

        # in a NixOS option for the environment.
        CGO_CFLAGS = optionalString isDarwin
          (builtins.concatStringsSep " " (builtins.filter (e: e != "") ([
            (builtins.getEnv "CGO_CFLAGS") ] ++ appleFrameworks)));
        CGO_LDFLAGS = builtins.concatStringsSep " " (builtins.filter (e: e != "") (
          [ (builtins.getEnv "CGO_LDFLAGS") ]
          ++ optionals isDarwin (["-lstdc++" "-lm" ] ++ appleFrameworks)

I'm not sure if we need all frameworks though.

I looked through the go source, CoreFoundation and Security is all that's needed

We already do in go:

depsTargetTargetPropagated = optionals stdenv.isDarwin [ Security Foundation ];

This means in a nix-shell there will be both frameworks presents.
Does go pickup our NIX_LDFLAGS/NIX_CFLAGS_COMPILE?
If not rather than wrapping the go compiler we could add a build support hook in go that also sets CGO_CFLAGS and CGO_LDFLAGS. All our C/C++ build infrastructure is build around nix-shell's hence we should stick for that with golang too. There things like pkg-config that also only work meaningful with nix-shell.
The problem of hard-coding is that it makes the go compiler inflexible. For instance it would include darwin frameworks even if you want no frameworks or frameworks for a different platform.

Also cc @LnL7 and @Ericson2314

Yep, it works with nix-shell. Under the hood cgo uses $CC. I have somehow overlooked that those frameworks were already being propagated.

But what I (and others) are running against is that you can't use the compiler directly outside of a nix-shell, since those NIX_LDFLAGS are not set.

Another solution might be for nix-Darwin et al to add flags that are set through depsTargetTargetPropagated (and similar things) in the environment, so the user's shell picks them up. This would emulate being in a nix-shell at all times.

I'd personally prefer the wrapper approach since it reduces the scope of where the flags get set.

Closing in favor of #91347