| Message ID | 87mshxkd89.fsf@gnu.org |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
Ludovic Courtès writes: > Janneke Nieuwenhuizen <janneke@gnu.org> skribis: > >> +++ b/gnu/packages/commencement.scm >> @@ -3643,10 +3643,12 @@ (define-public gcc-toolchain-14 >> ;; The default GCC >> (define (current-gcc-toolchain) >> "The current default gcc-toolchain version." >> - gcc-toolchain-11) >> + (if (target-hurd64?) >> + gcc-toolchain-14 >> + gcc-toolchain-11)) > > [...] > >> +++ b/gnu/packages/gcc.scm >> @@ -861,10 +861,12 @@ (define-public gcc-14 >> ;; the gcc-toolchain-* definitions. >> (define (current-gcc) >> "The current default gcc version." >> - gcc-11) >> + (if (target-hurd64?) >> + gcc-14 >> + gcc-11)) > > This affects not just cross-compilation but also native compilation. Eh, if you mean for the 64bit Hurd, sure! That was the idea, it needs gcc-14... > Let’s assume we only want cross-compilation to x86_64-gnu for now, Cross-compilation works pretty well, I've been mostly working on native compilation the past week... > how about changing the GCC version used for cross-compilation, and > only that: > > diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm > index 5781341a87..6120740b3c 100644 > --- a/gnu/packages/cross-base.scm > +++ b/gnu/packages/cross-base.scm > @@ -61,7 +61,7 @@ (define-syntax %xgcc > ;; > ;; Note: This is a macro so that we do not refer to 'gcc' from the top > ;; level, which would lead to circular-dependency issues. > - (identifier-syntax gcc)) > + (identifier-syntax gcc-14)) Interesting...I would have thought this would cause a world rebuild, because of the cross-gcc in commencement. Apparently, it doesn't. > That would affect also non-Hurd cross-compilation targets, but if it > works, it’s simpler. Ok, I very much like the simplicity of this. > Then, as a second step, we could prepare a ‘core-packages-team’ branch > that upgrades ‘gcc’ globally, and that way we keep something consistent > and simpler, without ‘current-gcc’. (Though it means we’d have to wait > before we can build natively on x86_64-gnu.) > > WDYT? I've been thinking about this route and decided against it because it seems to me that upgrading to gcc-14 will cause a lot of trouble/work. However, if that work is shared, and we have the build farm to help, it may be the best route. Maybe the wait doesn't have to be too long? Also, in the mean time, upstream support might improve. Maybe we can decide to go the route you propose and also keep this current-gcc patch on the hurd-team branch for a bit (we prepend a fat REMOVEME in front of it). We can keep working on native Hurd builds that use gcc-14 on hurd-team using this hack, until core-packages-team is ready to make it obsolete? Greetings, Janneke
Hi, <janneke@gnu.org> skribis: > Ludovic Courtès writes: [...] >> how about changing the GCC version used for cross-compilation, and >> only that: >> >> diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm >> index 5781341a87..6120740b3c 100644 >> --- a/gnu/packages/cross-base.scm >> +++ b/gnu/packages/cross-base.scm >> @@ -61,7 +61,7 @@ (define-syntax %xgcc >> ;; >> ;; Note: This is a macro so that we do not refer to 'gcc' from the top >> ;; level, which would lead to circular-dependency issues. >> - (identifier-syntax gcc)) >> + (identifier-syntax gcc-14)) > > Interesting...I would have thought this would cause a world rebuild, > because of the cross-gcc in commencement. Apparently, it doesn't. > >> That would affect also non-Hurd cross-compilation targets, but if it >> works, it’s simpler. > > Ok, I very much like the simplicity of this. Yay. >> Then, as a second step, we could prepare a ‘core-packages-team’ branch >> that upgrades ‘gcc’ globally, and that way we keep something consistent >> and simpler, without ‘current-gcc’. (Though it means we’d have to wait >> before we can build natively on x86_64-gnu.) >> >> WDYT? > > I've been thinking about this route and decided against it because it > seems to me that upgrading to gcc-14 will cause a lot of trouble/work. True. > However, if that work is shared, and we have the build farm to help, it > may be the best route. Maybe the wait doesn't have to be too long? > Also, in the mean time, upstream support might improve. Well yes, it’s going to take a bit of time, let’s face it. But hopefully quite a few of us would work on it and we’d set up ci.guix to build the branch. Also, with the reduced scope of ‘core-packages’, I hope it can be faster than ‘core-updates’ was before. And we can choose to have a cycle that changes very little beside GCC. > Maybe we can decide to go the route you propose and also keep this > current-gcc patch on the hurd-team branch for a bit (we prepend a fat > REMOVEME in front of it). We can keep working on native Hurd builds > that use gcc-14 on hurd-team using this hack, until core-packages-team > is ready to make it obsolete? Yes. At least, we can already merge cross-compilation support. Thanks, Ludo’.
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm index 5781341a87..6120740b3c 100644 --- a/gnu/packages/cross-base.scm +++ b/gnu/packages/cross-base.scm @@ -61,7 +61,7 @@ (define-syntax %xgcc ;; ;; Note: This is a macro so that we do not refer to 'gcc' from the top ;; level, which would lead to circular-dependency issues. - (identifier-syntax gcc)) + (identifier-syntax gcc-14)) (define %gcc-include-paths ;; Environment variables for header search paths.