New GCC packaging -- separating compilers from runtime libraries

[Ericson2314]

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.

[stale]

I marked this as stale due to inactivity. → More info

[danielbarter]

I have been exploring this. After the buildPhase of gcc.cc as it currently exists, all the of the libraries are split apart:

$ pwd
/tmp/build/x86_64-unknown-linux-gnu
$ ls
libatomic  libgcc  libgomp  libitm  libquadmath  libsanitizer  libssp  libstdc++-v3  libvtv

If we are willing to accept having them all built together, then splitting them into separate components at install time wouldn't be hard. We could have each library as a separate output of gcc.cc. At the very least, this would be a step towards fixing a lot of the issues related to using clang with the GNU C++ standard library.

Everything I said above seems kind of obvious, so there must be some reason why it isn't a great idea.

[Ericson2314]

@danielbarter I would like to separate at build time too, because it makes rebuilding cheap. See #132343 I just need to get some other things off my plate so I can get back to it.

(#82131 finally got fixed up, so there is hope for me finishing my TODO list :))

[danielbarter]

That makes a lot of sense. I was experimenting a bit more this morning and building the libraries individually is literally 30 seconds on my machine. Building gcc.cc as it exists today is 30 mins!

[ghost]

@Ericson2314 the exherbo links are broken, would you mind reposting them?

I know you sent them to me already; I opened them in the browser on my workstation and then left town and I won't be back for a few days. I need to stop using browser tabs as my to-do list.

[Ericson2314]

@amjoseph-nixpkgs sure, I will once I get home.

Also, do note I believe this is incremental. The only reason I didn't merge it yet (with the broken libraries removed) is because I was replacing the old libgcc and libstdc++ packages. We could just leave in place instead and then this would be completely standalone, like building the new bridge next to the old bridge that is to be replaced and then demolished.

I suppose that probably is then best route for this, but we can return to it after your boostrap one :).

[Ericson2314]

I finally fixed the links :)