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

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.

Let’s assume we only want cross-compilation to x86_64-gnu for now, how
about changing the GCC version used for cross-compilation, and only
that:
That would affect also non-Hurd cross-compilation targets, but if it
works, it’s simpler.

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?

Ludo’.
  

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

Ludovic Courtès writes:

Hello,

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

Pushed to master as ec8a5ec15f898e864705e5a5c834532e3fa8d0a4.

Greetings,
Janneke
  

Ludovic Courtès writes:

> 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?

Pushed a `core-packages-team' with (this one) gcc-14 commit.  Let the
fun begin :)

Greetings,
Janneke