build-support/cc-wrapper: add libstdc++fs into default library path for clang

[trofi]

After #210004 usbmuxd2 started failing to build as:

usbmuxd2-unstable> .../ld: cannot find -lstdc++fs: No such file or directory
usbmuxd2-unstable> clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

This started happening because #210004 exposed a long-standing bug in gcc derivation: cc.lib is missing libstdc++fs library:

$ find $(nix-build --no-link -A stdenv.cc.cc.lib) | fgrep libstdc | unnix

/<<NIX>>/gcc-11.3.0-lib/lib/libstdc++fs.la

/<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.la
/<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.so.6.0.29
/<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.so
/<<NIX>>/gcc-11.3.0-lib/lib/libstdc++.so.6

It was not moved from cc.out output:

$ find $(nix-build --no-link -A stdenv.cc.cc) | fgrep libstdc | unnix
/<<NIX>>/gcc-11.3.0/lib/libstdc++.a
/<<NIX>>/gcc-11.3.0/lib/libstdc++fs.a

This change adds cc library lookup path back to staging-next until gcc is fixed.`

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[trofi]

15k rebuilds, more than I expected, but maybe ~ok for staging-next?

$ ./maintainers/scripts/rebuild-amount.sh HEAD^
Estimating rebuild amount by counting changed Hydra jobs (parallel=unset).
      1 pkgs-lib-tests
      1 x86_64-darwin
  15523 x86_64-linux

I expected only affect the only packages that use clangStdenv in one form or another. But maybe it's something like mesa?

[trofi]

Yeah, it's most of graphical stack.

[ghost]

LGTM but could you mention in the commit message (maybe even in the title) that the extra flags are added only for clang?

Rebuilt full workstation on:

• x86_64-linux (except chromium+firefox, still building)
• powerpc64le-linux (except ghc, chromium+firefox, still building)

[ghost]

I agree, libraries belong in lib.

Unfortunately a ton of packages that have a $lib output are putting their .a files in $out. I think autotools even does this by default when you build both static and dynamic libraries (i.e. it doesn't use --libdir for the .a files). On my system, when scanning /nix/store/*-lib/ for .a files, the only hits are things that don't use autotools. Or it might be the way nixpkgs invokes ./configure. Anyways, the problem affects a lot more than just gcc.

This should probably be fixed nixpkgs-wide in setup.sh someday.

[trofi]

Unfortunately a ton of packages that have a $lib output are putting their .a files in $out.

From what I understand how library lookup works splitting .a and .so into different directories will effectively cause only one of them to be used as ld will use first found. I would expect most of the packages to put both together in a single directory.

I think autotools even does this by default when you build both static and dynamic libraries (i.e. it doesn't use --libdir for the .a files). On my system, when scanning /nix/store/*-lib/ for .a files, the only hits are things that don't use autotools. Or it might be the way nixpkgs invokes ./configure.

My understanding is that nixpkgs tries hard not to build both if possible (--enable-shared --disable-static / --disable-shared --enable-static). autotools should put both into --libdir. Even FHS distributions rely a lot on --libdir correct handling to put 32-vs-64 bit code into a correct location to make -m32/-m64 just work.

Anyways, the problem affects a lot more than just gcc.

Sure. Though most programs don't implement the split between host/target libraries. For simpler programs it should be only a matter of fixing build system to put results into a correct directory (--libdir or equivalent). gcc case is slightly more complicated than that. Otherwise we would not need this huge driver-wrapper that incorrectly reimplements gcc's assumed library search.

[trofi]

LGTM but could you mention in the commit message (maybe even in the title) that the extra flags are added only for clang?

Added for clang to commit summary.