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

["Ludovic Courtès" <ludo@gnu.org>]

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’.