C++ compilers: Be sane with standard libraries

[Ericson2314]

Motivation for this change

This is long overdue, @LnL7 Time for you to say "I told you so!" :).

CC @matthewbauer @TravisWhitaker

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built stdenv on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[Ericson2314]

Seeing that this is such a massive rebuild, on I am all ears on how we can do more nix and less bash to make the inevitable follow-up work easier.

Maybe we could purely concat lists for all those *flags file and write once? The building detection the wrapper script does currently I am not too pleased with.

[matthewbauer]

We may need a migration or warning for this.

It may not be actively used though

[Mic92]

aliases.nix should be enough.

[Ericson2314]

I am not sure what should be aliased?

[Mic92]

Not aliased but we need a throw statement in aliases.nix that generates a warning stating that this file has been removed.

[Ericson2314]

Ah! sounds good.

[matthewbauer]

This may be used outside by wrappers outside of nixpkgs. might be worth keeping, but just as meta-information.

[Ericson2314]

It might be, but I think that's bad :)

[matthewbauer]

There's no good way to use libraries that want these c flags without some meta-info like this. For instance bindgen in rust or anything that uses libclang. If we're going to be removing it, we should at least have a replacement.

[matthewbauer]

see #26474 for why this was exported

[Ericson2314]

Right I would rather have a more general way to get flags and just this one in particular. The default part (i.e. miy get overriden) is no good too.

[matthewbauer]

Maybe we should just expose all of these flags in the cc-wrapper ? Something like stdenv.cc.cflags_compile and stdenv.cc.ld_flags

[matthewbauer]

that is the pre-substituted values since we don't know the actual values at evaluation

[Ericson2314]

It would be nice to uses more Nix so we did know the values. (e.g. have a nix boolean and then assert at run-time it was correct.)

[matthewbauer]

I think that requires Nix-level setup-hooks to work correctly. I think that might be too ambitious for now.

[matthewbauer]

I'm thinking something like /nix-support/get-cflags.sh which does all of this for you.

[Ericson2314]

Well getting all the -I flags for other packaged requires that, but not just the std library stuff I think.

[matthewbauer]

Right these should just need the basic c/c++ headers and library paths.

[matthewbauer]

I think we can also remove some of the old hacks like in https://github.com/NixOS/nixpkgs/pull/26709/files too

[LnL7]

Does that change here? I would expect this to still only include it for clang++. Come to think of it, wouldn't CC=$CXX be a nicer fix for those cases or does that not work?

[LnL7]

Would it make sense to expose the libc++ of the compiler, similar to libc?

[Ericson2314]

Yeah, though null for libstdc++ is rather unfortunate. Oh well, all the more reason to get on splitting up the GCC derivation.

[LnL7]

Perhaps for now cc.libcxx = gcc would make sense? Maybe that could also solve cc ? gcc.

[Ericson2314]

I'm on the fence about this---I do want to get rid of cc.gcc but it's a bit disingenous unless we can somehow filter the other libraries out. Maybe we can leave that for a follow-up PR?

[Ericson2314]

#91293 got rid of cc.gcc here.

[matthewbauer]

Does that change here? I would expect this to still only include it for clang++. Come to think of it, wouldn't CC=$CXX be a nicer fix for those cases or does that not work?

Yeah, you're right - I was forgetting what the issue was there. We still need CXX to be used.

[Ericson2314]

OK with the last push I have both stdenvs building, so now we can clean up in earnest.

[Mic92]

We also have some tools that consume the c/c++ standard includes: cquery, clang-tools and ccls

[Mic92]

We also have some tools that consume the c/c++ standard includes: cquery, clang-tools and ccls

As it turns out those are not affected by this change. I removed cquery last week. Clangd and CCLS only take the libcxx include path as input. I remember to use default_cxx_stdlib_compile for youcompletme at some point, but this was more of a hack and using something like ${llvmPackages.libcxx}/include/c++/v1 would be cleaner.

[Ericson2314]

OK, it evals! I don't think we need any more back-compat stuff ATM, but happy to add things in requested.