We've split up the LLVM toolchain in this manner, which has been great for build times and managing complexity. GCC, however, needs the same treatment, however. We should do this for GCC's own sake, and also because not until both toolchains are so cleaned up can we make vast simplifications to cc-wrapper, etc.

The best precedent for how to do this is the Exherbo distro's packaging of GCC:

• compiler: https://git.exherbo.org/arbor.git/tree/packages/sys-devel/gcc https://gitlab.exherbo.org/exherbo/arbor/-/tree/master/packages/sys-devel/gcc
• libraries: https://git.exherbo.org/arbor.git/tree/packages/sys-libs https://gitlab.exherbo.org/exherbo/arbor/-/tree/master/packages/sys-libs

There is also https://github.com/richfelker/musl-cross-make, which is doing what we want to do, but in a more BSD-style, one-big-make-invocation manner.

Lastly, there have also been a few attempts in this direction before on the Nixpkgs side:

• libgcc: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gcc/libgcc/default.nix
• libstdc++: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/{libraries/gcc/libstdc++/5.nix
• Feature/gcc ng #40637 which does something somewhat like what this issue proposes.