GNU bug report logs - #74290
[PATCH 00/31] Add support for x86_64-gnu, aka the 64bit Hurd.

Previous Next

Full log

View this message in rfc822 format

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 74290 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>, Ekaitz Zarraga <ekaitz <at> elenq.tech>, Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>, Tobias Geerinckx-Rice <me <at> tobias.gr>, Efraim Flashner <efraim <at> flashner.co.il>, Andreas Enge <andreas <at> enge.fr>, Christopher Baines <guix <at> cbaines.net>
Subject: [bug#74290] [PATCH v2 05/40] gnu: Add basic support for x86_64-pc-gnu target, aka 64bit Hurd.
Date: Tue, 03 Dec 2024 08:41:46 +0100

Ludovic Courtès writes:

Hello,

> <janneke <at> 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.

Pushed to master as ec8a5ec15f898e864705e5a5c834532e3fa8d0a4.

Greetings,
Janneke

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.