cc-wrapper: clean-up post stdenvAdapters.useLibsFrom: init

[SomeoneSerge]

...from "cudaPackages.backendStdenv: useGccForLibs", 210ce38

Description of changes

#275947 (based on @rrbutani's suggestions and PoC) introduced (without approval) passthru attributes in the cc-wrapper, the purpose of which is to allow propagating the standard c++ libraries used by another wrapper. These attributes are now (ab)used to fix the libstdc++ compatibility issues in cudaSupport = true packages and in python3Packages.tensorflow, which use older gcc than the rest of nixpkgs.

As #275947 (comment) points out, this had introduced more junk in the wrapper, lacks longer-term vision, etc.

This draft is a placeholder just removing the not-so-useful comments introduced by the preceding PR, but I'm hoping we can also have a conversation about whether the passthru solution hits a local minima, about what the other cc-wrapper bits touched by the PR were actually intended for, etc.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[SomeoneSerge]

This:

nixpkgs/pkgs/build-support/cc-wrapper/default.nix

Lines 113 to 114 in ff1232c

	# Analogously to cc_solib and gccForLibs_solib
	libcxx_solib = "${lib.getLib libcxx}/lib";

used to be this:

nixpkgs/pkgs/build-support/cc-wrapper/default.nix

Line 567 in 1a5bd69

echo " -L${lib.getLib libcxx}/lib" >> $out/nix-support/cc-ldflags

Afaiu this was exactly the same logic as

nixpkgs/pkgs/build-support/cc-wrapper/default.nix

Lines 439 to 441 in 1a5bd69

	+ optionalString useGccForLibs ''
	echo "-L${gccForLibs}/lib/gcc/${targetPlatform.config}/${gccForLibs.version}" >> $out/nix-support/cc-ldflags
	echo "-L${gccForLibs_solib}/lib" >> $out/nix-support/cc-ldflags

...is that correct?

[SomeoneSerge]

As the description mentions, the prime motivation of the cc-wrapper change was to be able to inherit the nixpkgs' default stdenv's libraries (primarily, libstdc++ on {x86_64,aarch64}-linux) in compat stdenvs, e.g. when using an older gcc.

I still find it questionable e.g. to

1. pass wrappCCWith the wrapped (g)cc instead of of the unwrapped lib output,
2. pass the stdenv instead of the lib in stdenvAdapters.useLibsFrom.

[SomeoneSerge]

In relation to #281371: it isn't enough to propagate the pkgs.stdenv's libraries to the adapted stdenv, it's also necessary to take the other stdenv's (e.g. pkgs.gcc11Stdenv's) native platform's tools, e.g. coreutils:

nixpkgs/pkgs/build-support/cc-wrapper/default.nix

Lines 90 to 91 in 09f9f1f

	# The wrapper scripts use 'cat' and 'grep', so we may need coreutils.
	coreutils_bin = optionalString (!nativeTools) (getBin coreutils);

Currently these aren't exposed in passthru or anyhow (except for env, which barely can be considered a part of the public interface)

[SomeoneSerge]

The question regarding

nixpkgs/pkgs/stdenv/adapters.nix

Lines 244 to 246 in 2589d8b

	/* NOTE: cc.cc is the unwrapped compiler. Should we respect the old
	* wrapper instead? */
	cc = targetStdenv.cc.cc;

is "do cc-wrappers compose"? In the current form, useLibsFrom pkgs.stdenv pkgsStatic.gcc11Stdenv is going to discard all of the flags related to static linkage I'm pretty sure