Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New GCC packaging -- separating compilers from runtime libraries #132340

Open
Ericson2314 opened this issue Aug 1, 2021 · 7 comments
Open

New GCC packaging -- separating compilers from runtime libraries #132340

Ericson2314 opened this issue Aug 1, 2021 · 7 comments
Labels
0.kind: packaging request Request for a new package to be added significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc.

Comments

@Ericson2314
Copy link
Member

Ericson2314 commented Aug 1, 2021

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:

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:

@stale
Copy link

stale bot commented Apr 30, 2022

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

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 30, 2022
@sternenseemann sternenseemann removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 30, 2022
@danielbarter
Copy link
Contributor

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
Copy link
Member Author

Ericson2314 commented Nov 4, 2022

@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
Copy link
Contributor

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
Copy link

ghost commented Feb 21, 2023

@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
Copy link
Member Author

@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
Copy link
Member Author

I finally fixed the links :)

@infinisil infinisil added the significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc. label Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: packaging request Request for a new package to be added significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc.
Projects
None yet
Development

No branches or pull requests

4 participants