[bug#74290] [PATCH v2 05/40] gnu: Add basic support for x86_64-pc-gnu target, aka 64bit Hurd.

[janneke]

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


-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com