gccNGPackages: init #414299
gccNGPackages: init #414299
Conversation
RossComputerGuy
force-pushed
the
feat/gcc-ng
branch
from
4f1e2e1 to
56e1b40
Compare
github-actions
bot
added
10.rebuild-darwin: 1-10
|
Instant subscribe. Wishing you incredibly well on this journey. |
RossComputerGuy
force-pushed
the
feat/gcc-ng
branch
2 times, most recently
from
d7286b9 to
dc2bb16
Compare
nixpkgs-ci
bot
added
10.rebuild-darwin: 11-100
|
Cross compilation and native compilation of GNU hello works. |
RossComputerGuy
force-pushed
the
feat/gcc-ng
branch
from
dc2bb16 to
ca6991b
Compare
nixpkgs-ci
bot
added
the
9.needs: reviewer
There was a problem hiding this comment.
Now that we are close to merging, can we do my original three commits (and anything else you need on top) rather than one squashed one?
(Note that the previous GCC NG PRs also had one squashed. The originals come from https://github.com/Ericson2314/gcc/tree/prog-target-14 as I mentioned before.)
There was a problem hiding this comment.
I'm not sure what exactly you're meaning here. Like 3 separate patches from that branch?
nixpkgs-ci
bot
removed
the
9.needs: reviewer
There was a problem hiding this comment.
We might want to do that before merging?
There was a problem hiding this comment.
Actually find waiting on some of the other patches, as we might get feedback on how the exe lookup ought to work in general one one patch that would affect the other patches
There was a problem hiding this comment.
Did we have this before? What exactly is going on? Seems like this should be not buildGccPackages but the same package set as GCC itself? At least if GCC is going to link these?
Is this the top-level configure you are using? can we use a GCC subdir instead to avoid some of this?
There was a problem hiding this comment.
This is a new thing to help minimize build times, I was able to save about 3 minutes by using a Nix built set of libraries. My hope is that later on, we can explicitly get GCC to not build it without forcing it like I did.
There was a problem hiding this comment.
OK that sounds good. I see comparing to the earlier versions of this that this is not a different approach but just added stuff to the same approach -- I was worried you might be doing this instead of just CD'ing to a subproject, but I see that is not the case.
Ericson2314
left a comment
Ericson2314
left a comment
There was a problem hiding this comment.
Just a few things, almost there!
RossComputerGuy
force-pushed
the
feat/gcc-ng
branch
from
9811c68 to
7b1f44a
Compare
Ericson2314
left a comment
Ericson2314
left a comment
There was a problem hiding this comment.
OK yes just squash out my commit (I didn't want to force push to your branch) and this is ready to go! So excited!!!
nixpkgs-ci
bot
added
the
12.approvals: 1
RossComputerGuy
force-pushed
the
feat/gcc-ng
branch
from
7b1f44a to
101bb13
Compare
|
Congratulations!!! |
|
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689354.html for the record, email about upstreaming one of the patches that I just sent. |
| }: | ||
| let | ||
| inherit (stdenv) targetPlatform hostPlatform; | ||
| targetPrefix = lib.optionalString (targetPlatform != hostPlatform) "${targetPlatform.config}-"; |
There was a problem hiding this comment.
@RossComputerGuy A bit late to the party, but in #389469 I fixed a somewhat obscure cross-compilation bug by using lib.systems.equals consistently everywhere for gcc, but in this ng version some direct equality checks are present again. I think it would be good to keep things consistent from the start. I can make PR for this, but maybe it's easier if you do it while you're still fixing things?
There was a problem hiding this comment.
I don't think this is something we can change without messing with the CC wrapper and stdenv. When you use pkgsLLVM or any of the variants, you create a cross environment. This usage is simple enough it won't create issues.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/blog-post-compiler-bootstrapping-in-nixpkgs/66791/1 |
|
Looks like |
|
Good catch, @trofi. Yes, I imagine we'll need many rounds of syncing things up. |
|
Proposed |
| + c_file_name = p; | ||
| + | ||
| + if (c_file_name) { | ||
| + is_cross_compiler = strncmp(basename(c_file_name), target_machine, strlen(target_machine)) == 0; |
There was a problem hiding this comment.
Uh oh - there is issues here!
for one, basename requires #include <libgen.h>. On glibc, you are lucky and this is implicitly already included. On musl, well, its completely broken.
According to the manpage:
basename(3) Library Functions Manual basename(3)
NAME
basename, dirname - parse pathname components
LIBRARY
Standard C library (libc, -lc)
SYNOPSIS
#include <libgen.h>
char *dirname(char *path);
char *basename(char *path);
Another issue:
https://github.com/gcc-mirror/gcc/blob/1b306039ac49f8ad91ca71d3de3150a3c9fa792a/gcc/collect2.cc#L221
const char *c_file_name; /* pathname of gcc */c_file_name is const, meaning you can't just call basename and expect things to work. Ordinarily i would suggest just adding a strdup, but turns out strdup is poisoned here.
As it stands, pkgsMusl.gccNGPackages_15.libssp (what i actually wanted to build) is broken indirectly, i suspect pkgsMusl.gccNGPackages_15.gccNoLibgcc is the attrpath to the smallest reproducer.
There was a problem hiding this comment.
(I don't know anything about gccNGPackages). gcc uses lbasename() from local libiberty.a in a few places. Might work here as is.
I wonder why you need libssp. Just to make sure it builds? Otherwise musl should use it's facility to implement ssp primitives: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=b6d9608d5994f559fe7b1ccd1deb86a530195615;hb=HEAD#l6949
*-*-musl*)
# All versions of musl provide stack protector
gcc_cv_libc_provides_ssp=yes;;
But there are probably some target-specific caveats like 32-bit x86, 32-bit ppc and mips.
There was a problem hiding this comment.
I wonder why you need
libssp. Just to make sure it builds? Otherwisemuslshould use it's facility to implementsspprimitives:
I was building netbsd.fts on llvm-native musl against #463395, and that failed to include ssp/ssp.h. There might be more things going on, but i figured i'd just try and see what happens if i give it ssp.
But even then, gcc 15 ng should work on musl, even if my use case here turns out to be bogus and some other issue.
There was a problem hiding this comment.
diff --git a/pkgs/development/compilers/gcc/ng/15/gcc/fix-collect2-paths.diff b/pkgs/development/compilers/gcc/ng/15/gcc/fix-collect2-paths.diff
index 1fac49766044..eed303ae4a0b 100644
--- a/pkgs/development/compilers/gcc/ng/15/gcc/fix-collect2-paths.diff
+++ b/pkgs/development/compilers/gcc/ng/15/gcc/fix-collect2-paths.diff
@@ -155,7 +155,7 @@ index 268ac378b9c..8a5c606075a 100644
+ c_file_name = p;
+
+ if (c_file_name) {
-+ is_cross_compiler = strncmp(basename(c_file_name), target_machine, strlen(target_machine)) == 0;
++ is_cross_compiler = strncmp(lbasename(c_file_name), target_machine, strlen(target_machine)) == 0;
+ }
+
+ for (i = 0; i < USE_LD_MAX; i++)this does indeed fix the build fwiw
There was a problem hiding this comment.
I was building
netbsd.ftson llvm-native musl against #463395, and that failed to includessp/ssp.h. There might be more things going on, but i figured i'd just try and see what happens if i give it ssp.
I don't think we even use GCC NG currently by default so this would probably be a problem with regular GCC.
There was a problem hiding this comment.
oh yeah no, regular musl (built with regular gcc) breaks and can't build gcc ng. That was just motivation for why i was even trying in the first place, but just musl gccng reproduces.
7 participants
Things done
GCC built like LLVM where we've split things into their individual components.
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.