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

Previous Next

Package: guix-patches;

Reported by: Janneke Nieuwenhuizen <janneke <at> gnu.org>

Date: Sun, 10 Nov 2024 10:35:02 UTC

Severity: normal

Tags: patch

Done: Janneke Nieuwenhuizen <janneke <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: <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: Mon, 18 Nov 2024 10:07:33 +0100
>> Ludovic Courtès writes:
>>
>>> Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:
>>>
>>> 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?
>
> So, what about if we do, in addition to the %xgcc => gcc-14 in
> cross-base -- we use gcc-14 on the 64bit hurd /system/:
>
> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index a14de3002f..2b0b4b07b4 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -3642,7 +3642,9 @@ (define-public gcc-toolchain-14
>  
>  ;; The default GCC
>  (define-public gcc-toolchain
> -  gcc-toolchain-11)
> +  (if (system-hurd64?)

Hmm, no that doesn't work; (%current-system) is #f at toplevel.  We
could only do something like

  (define (host-hurd64?)
    (let ((uname-info (uname)))
      (and (equal? (utsname:sysname uname-info) "GNU")
           (equal? (utsname:machine uname-uname) "x86_64"))))

and then it still would not work for offloading.  It might be a cleanish
way to enable development in the 64bit childhurd before the full gcc-14
transition?

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




This bug report was last modified 175 days ago.

Previous Next


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