Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Tobias Platen]

For me the best way to run 32 bit powerpc software,
is using KVM on a POWER9 system. The https://www.powerpc-notebook.org/
will run 32 bit software as well. 

Tobias

On Wed, 26 May 2021 16:09:29 +0200
Ludovic Courtès  wrote:

> Hi,
> 
> Efraim Flashner  skribis:
> 
> > On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote:
> 
> [...]
> 
> >> Maybe it’s more readable to keep it as a bullet list, like:
> >> 
> >>   @item mips64el-linux (@emph{unsupported})
> >>   …
> >> 
> >>   @item powerpc-linux (@emph{unsupported})
> >>   …
> >> 
> >> with a sentence explaining what “unsupported” means.
> >
> > That was kind-of my idea with grouping them together
> 
> Yes, but people who just skim through that page may just see that
> ‘powerpc-linux’ is listed, without noticing that there’s a sentence ten
> line above that says “The following arches are not supported”.  Having
> “unsupported” next to it should avoid that (yes, I’ve learned to be
> super cautious.  :-)).
> 
> >> IMO guix.m4 should either require --with-courage or emit a prominent
> >> warning for these.
> 
> [...]
> 
> > The problem then becomes whoever tinkers with it will have to keep
> > either a custom guix.m4 for their guix package or a custom guix package
> > with "--with-courage" as a configure-flag.
> 
> True.  In that case, let it go without ‘--with-courage’ but emit a
> warning with AC_MSG_WARN that points to the relevant section of the
> manual.
> 
> Deal?
> 
> Thanks!
> 
> Ludo’.
> 


-- 
Tobias Platen 

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote:

[...]

>> Maybe it’s more readable to keep it as a bullet list, like:
>> 
>>   @item mips64el-linux (@emph{unsupported})
>>   …
>> 
>>   @item powerpc-linux (@emph{unsupported})
>>   …
>> 
>> with a sentence explaining what “unsupported” means.
>
> That was kind-of my idea with grouping them together

Yes, but people who just skim through that page may just see that
‘powerpc-linux’ is listed, without noticing that there’s a sentence ten
line above that says “The following arches are not supported”.  Having
“unsupported” next to it should avoid that (yes, I’ve learned to be
super cautious.  :-)).

>> IMO guix.m4 should either require --with-courage or emit a prominent
>> warning for these.

[...]

> The problem then becomes whoever tinkers with it will have to keep
> either a custom guix.m4 for their guix package or a custom guix package
> with "--with-courage" as a configure-flag.

True.  In that case, let it go without ‘--with-courage’ but emit a
warning with AC_MSG_WARN that points to the relevant section of the
manual.

Deal?

Thanks!

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Tue, May 11, 2021 at 10:24:03PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Efraim Flashner  skribis:
> 
> > How about changing the mips64el documentation to say that there is
> > minimal support for the two architectures, with no substitutes, and may
> > be fun for tinkerers with the hardware. Then we could also change the
> > check in the guix.m4 to add mips64el-linux as supported in case anyone
> > does actually want to play with it.
> 
> No, not as “supported”, I surely don’t want to deal with mips64el-linux
> bugs.  :-)
> 
> > Current text:
> >
> > @item mips64el-linux (deprecated)¬
> > little-endian 64-bit MIPS processors, specifically the Loongson series,
> > n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
> > supported; in particular, there is no ongoing work to ensure that this
> > architecture still works.  Should someone decide they wish to revive this
> > architecture then the code is still available.
> >
> > Proposed text:
> >
> > @item Alternative architectures
> > In addition to architectures which are actually supported there are a
> > few formally unsupported architectures which may be of interested to
> > tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors,
> > specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian
> > 32-bit POWER processors, specifically the PowerPC 74xx series. There are
> > no installation tarballs, substitutes or promises that these
> > architectures are functional.
> >
> > And then I'd move it lower than the powerpc64le-linux entry.
> 

Ah, I didn't see your email.

> Maybe it’s more readable to keep it as a bullet list, like:
> 
>   @item mips64el-linux (@emph{unsupported})
>   …
> 
>   @item powerpc-linux (@emph{unsupported})
>   …
> 
> with a sentence explaining what “unsupported” means.

That was kind-of my idea with grouping them together

> IMO guix.m4 should either require --with-courage or emit a prominent
> warning for these.
> 
> WDYT?
> 
> Thanks,
> Ludo’.
> 

The problem then becomes whoever tinkers with it will have to keep
either a custom guix.m4 for their guix package or a custom guix package
with "--with-courage" as a configure-flag.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> How about changing the mips64el documentation to say that there is
> minimal support for the two architectures, with no substitutes, and may
> be fun for tinkerers with the hardware. Then we could also change the
> check in the guix.m4 to add mips64el-linux as supported in case anyone
> does actually want to play with it.

No, not as “supported”, I surely don’t want to deal with mips64el-linux
bugs.  :-)

> Current text:
>
> @item mips64el-linux (deprecated)¬
> little-endian 64-bit MIPS processors, specifically the Loongson series,
> n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
> supported; in particular, there is no ongoing work to ensure that this
> architecture still works.  Should someone decide they wish to revive this
> architecture then the code is still available.
>
> Proposed text:
>
> @item Alternative architectures
> In addition to architectures which are actually supported there are a
> few formally unsupported architectures which may be of interested to
> tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors,
> specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian
> 32-bit POWER processors, specifically the PowerPC 74xx series. There are
> no installation tarballs, substitutes or promises that these
> architectures are functional.
>
> And then I'd move it lower than the powerpc64le-linux entry.

Maybe it’s more readable to keep it as a bullet list, like:

  @item mips64el-linux (@emph{unsupported})
  …

  @item powerpc-linux (@emph{unsupported})
  …

with a sentence explaining what “unsupported” means.

IMO guix.m4 should either require --with-courage or emit a prominent
warning for these.

WDYT?

Thanks,
Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Thu, May 06, 2021 at 04:38:38PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner  skribis:
> 
> > On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote:
> 
> [...]
> 
> >>   3. OTOH, what will be the status of this architecture?  I don’t think
> >>  new 32-bit PPC hardware is being made (right?), so I guess we
> >>  probably won’t have substitutes for that architecture.  That means
> >>  it won’t be supported at the same level as other architectures and
> >>  may quickly suffer from bitrot.
> >
> > I don't know about new 32-bit powerpc hardware, I think it's only being
> > newly created for the embedded and networking space. As far as operating
> > systems with support¹ Adélie Linux is the only one I know that's
> > actually targeting the machines.
> >
> > I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is
> > faster than building on native hardware (1 core, 1.5GB of RAM, original
> > 4200 RPM disk), edging it out on single threaded compiling and doing
> > great when it comes to using multiple cores and parallel builds.
> > Ignoring how to create an OS image if we just targeted, say, mesa and
> > maybe one or two other packages, we could have a core set which doesn't
> > change regularly and won't take up too much emulated build time but will
> > save days of compile time.
> 
> [...]
> 
> > The fear of bit-rot is real and I think we should mention in the manual
> > (when I actually write the section) that support is best-effort with
> > minimal substitutes.
> 
> I feel like “best-effort with minimal substitutes” is already more than
> I’d be willing to commit to as a maintainer.

I have also learned that 'best effort' is a grey area in other circles;
does it mean you'll move mountains and spare no expense (The Best
Effort!™) or that you'll give it a shot but make no promises. I
definitely meant the second.

> We just added POWER9, for which we have actual hardware, and even
> getting to this minimal state where we provide a binary tarball required
> quite some effort.
> 
> Doing the same with 32-bit PowerPC would require us to set up emulation;
> we wouldn’t even have real hardware.
> 
> All in all, my preference would be to take the patches but not mention
> PowerPC 32-bit support anywhere, or at least, not provide substitutes
> and binary installation tarball.  IOW, few people would know whether it
> actually works :-) but tinkerers could still play with it.
> 
> WDYT?
> 
> Ludo’.

How about changing the mips64el documentation to say that there is
minimal support for the two architectures, with no substitutes, and may
be fun for tinkerers with the hardware. Then we could also change the
check in the guix.m4 to add mips64el-linux as supported in case anyone
does actually want to play with it.

Current text:

@item mips64el-linux (deprecated)¬
little-endian 64-bit MIPS processors, specifically the Loongson series,
n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
supported; in particular, there is no ongoing work to ensure that this
architecture still works.  Should someone decide they wish to revive this
architecture then the code is still available.

Proposed text:

@item Alternative architectures
In addition to architectures which are actually supported there are a
few formally unsupported architectures which may be of interested to
tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors,
specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian
32-bit POWER processors, specifically the PowerPC 74xx series. There are
no installation tarballs, substitutes or promises that these
architectures are functional.

And then I'd move it lower than the powerpc64le-linux entry.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Thu, May 06, 2021 at 04:45:30PM +0200, Ludovic Courtès wrote:
> Efraim Flashner  skribis:
> 
> > * gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two
> > phases to adjust for 32-bit big-endian systems.
> 
> [...]
> 
> > + (add-after 'unpack 'adjust-bootstrap-flags
> > +   (lambda _
> > + ;; Upstream knows about suggested solution.
> > + ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214
> 
> The first comment line should preferably mention the problem, like:
> 
>   ;; Change optimization flags to work around crash on
>   ;; 32-bit big-endian architectures: .
> 
> > + (substitute* "bootstrap/Makefile.in"
> > +   (("^GUILE_OPTIMIZATIONS.*")
> > +"GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives 
> > -Ocps\n"
> > + (add-after 'unpack 'remove-failing-tests
> > +   (lambda _
> > + ;; TODO: Discover why this test fails on powerpc-linux
> > + (delete-file 
> > "test-suite/standalone/test-out-of-memory"))
> 
> I’m surprised removing the executable works.  See
> ‘guile-2.2-skip-oom-test.patch’.

I took another look at it and I'm building 3.0.5 again but with
the 'remove-failing-tests phase removed. We'll find out in about 42
hours if it's needed or not.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Thu, May 06, 2021 at 04:48:09PM +0200, Ludovic Courtès wrote:
> Efraim Flashner  skribis:
> 
> > * gnu/packages/disk.scm (mac-fdisk): New variable.
> > * gnu/packages/patches/mac-fdisk-gentoo-patchset.patch,
> > gnu/packages/patches/mac-fdisk-p18.patch: New files.
> > * gnu/local.mk (dist_patch_DATA): Register them.
> 
> [...]
> 
> > +++ b/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
> > @@ -0,0 +1,866 @@
> > +https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/mac-fdisk/files
> 
> 
> [...]
> 
> > +++ b/gnu/packages/patches/mac-fdisk-p18.patch
> > @@ -0,0 +1,2070 @@
> > +This is the result of unzipping the 0.1-18 diff.gz
> > +https://cdn-aws.deb.debian.org/debian/pool/main/m/mac-fdisk/mac-fdisk_0.1-18.diff.gz
> 
> Given the size of these patches, please add a couple of sentences
> explaining what they do.
> 
> It would be best if we could refer to a fork instead of carrying those
> patches, though.
> 
> Ludo’.

I think I'm going to sit on the mac-fdisk package for a while. It would
be good to cut down the patches a bit. And I have to actually test it at
some point.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Maxime Devos  skribis:

> Efraim Flashner schreef op do 22-04-2021 om 10:59 [+0300]:
>> * gnu/packages/version-control.scm (mercurial)[arguments]: Skip tests on
>> powerpc-linux.
>> ---
>>  gnu/packages/version-control.scm | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> Unchanged since last patchset, IMO not ready for upstreaming.
>> 
>> diff --git a/gnu/packages/version-control.scm 
>> b/gnu/packages/version-control.scm
>> index 4d4b276a10..13e2ccd400 100644
>> --- a/gnu/packages/version-control.scm
>> +++ b/gnu/packages/version-control.scm
>> @@ -1688,7 +1688,11 @@ execution of any hook written in any language before 
>> every commit.")
>>   "--slowtimeout" "86400"
>>   ;; The test suite takes a long time and produces 
>> little
>>   ;; output by default.  Prevent timeouts due to 
>> silence.
>> - "-v"
>> + "-v"))
>> +   ;; Tests on powerpc-linux take more than 10 hours.
>> +   #:tests? ,(if (string=? "powerpc-linux" (or (%current-system)
>> +   
>> (%current-target-system)))
>> +   '#f '#t)))
>
> You can remove ' in '#f and '#t here.

You can even write:

  #:tests? (not (string-prefix? "powerpc-" (or …)))

Note: use ‘string-prefix?’ because ‘%current-target-system’ returns a
triplet, not a “system type”.

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Efraim Flashner  skribis:

> * gnu/packages/disk.scm (mac-fdisk): New variable.
> * gnu/packages/patches/mac-fdisk-gentoo-patchset.patch,
> gnu/packages/patches/mac-fdisk-p18.patch: New files.
> * gnu/local.mk (dist_patch_DATA): Register them.

[...]

> +++ b/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
> @@ -0,0 +1,866 @@
> +https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/mac-fdisk/files


[...]

> +++ b/gnu/packages/patches/mac-fdisk-p18.patch
> @@ -0,0 +1,2070 @@
> +This is the result of unzipping the 0.1-18 diff.gz
> +https://cdn-aws.deb.debian.org/debian/pool/main/m/mac-fdisk/mac-fdisk_0.1-18.diff.gz

Given the size of these patches, please add a couple of sentences
explaining what they do.

It would be best if we could refer to a fork instead of carrying those
patches, though.

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Efraim Flashner  skribis:

> * gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two
> phases to adjust for 32-bit big-endian systems.

[...]

> + (add-after 'unpack 'adjust-bootstrap-flags
> +   (lambda _
> + ;; Upstream knows about suggested solution.
> + ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214

The first comment line should preferably mention the problem, like:

  ;; Change optimization flags to work around crash on
  ;; 32-bit big-endian architectures: .

> + (substitute* "bootstrap/Makefile.in"
> +   (("^GUILE_OPTIMIZATIONS.*")
> +"GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives 
> -Ocps\n"
> + (add-after 'unpack 'remove-failing-tests
> +   (lambda _
> + ;; TODO: Discover why this test fails on powerpc-linux
> + (delete-file 
> "test-suite/standalone/test-out-of-memory"))

I’m surprised removing the executable works.  See
‘guile-2.2-skip-oom-test.patch’.

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Hi Efraim,

Efraim Flashner  skribis:

> On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote:

[...]

>>   3. OTOH, what will be the status of this architecture?  I don’t think
>>  new 32-bit PPC hardware is being made (right?), so I guess we
>>  probably won’t have substitutes for that architecture.  That means
>>  it won’t be supported at the same level as other architectures and
>>  may quickly suffer from bitrot.
>
> I don't know about new 32-bit powerpc hardware, I think it's only being
> newly created for the embedded and networking space. As far as operating
> systems with support¹ Adélie Linux is the only one I know that's
> actually targeting the machines.
>
> I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is
> faster than building on native hardware (1 core, 1.5GB of RAM, original
> 4200 RPM disk), edging it out on single threaded compiling and doing
> great when it comes to using multiple cores and parallel builds.
> Ignoring how to create an OS image if we just targeted, say, mesa and
> maybe one or two other packages, we could have a core set which doesn't
> change regularly and won't take up too much emulated build time but will
> save days of compile time.

[...]

> The fear of bit-rot is real and I think we should mention in the manual
> (when I actually write the section) that support is best-effort with
> minimal substitutes.

I feel like “best-effort with minimal substitutes” is already more than
I’d be willing to commit to as a maintainer.

We just added POWER9, for which we have actual hardware, and even
getting to this minimal state where we provide a binary tarball required
quite some effort.

Doing the same with 32-bit PowerPC would require us to set up emulation;
we wouldn’t even have real hardware.

All in all, my preference would be to take the patches but not mention
PowerPC 32-bit support anywhere, or at least, not provide substitutes
and binary installation tarball.  IOW, few people would know whether it
actually works :-) but tinkerers could still play with it.

WDYT?

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Sat, Apr 17, 2021 at 12:51:01PM -0700, Chris Marusich wrote:
> Efraim Flashner  writes:
> 
> > * gnu/packages/base.scm (binutils)[arguments]: Add phase on
> > powerpc-linux to adjust the test suite.
> > * gnu/packages/commencement.scm (binutils-boot0)[arguments]: Move custom
> > phases after inherited arguments. Add phase on powerpc-linux to adjust
> > the test suite.
> 
> Nits: adjust the test suite to do what?  The message would be clearer if
> it explained the purpose of the adjustment.  You could also name the
> phases you added/moved, for extra clarity, if you want to.
> 
> > diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> > index dbb7c619fe..b9fc0a6e29 100644
> > --- a/gnu/packages/base.scm
> > +++ b/gnu/packages/base.scm
> > @@ -531,7 +531,16 @@ change.  GNU make offers many powerful extensions over 
> > the standard utility.")
> >  
> >;; Make sure 'ar' and 'ranlib' produce archives 
> > in a
> >;; deterministic fashion.
> > -  "--enable-deterministic-archives")))
> > +  "--enable-deterministic-archives")
> > +  ,@(if (string=? (%current-system) "powerpc-linux")
> > +  `(#:phases
> > +(modify-phases %standard-phases
> > +  (add-after 'unpack 'disable-rust-libiberty-test
> > +(lambda _
> > +  (substitute* "libiberty/testsuite/Makefile.in"
> > +((" check-rust-demangle ") ""))
> > +  #t
> > +  '(
> 
> What's the problem?  Presumably the test fails; a comment here could
> clarify that.
> 
> If it's a test failure, has the issue been reported upstream?

I'll check to see if I can find something upstream. If not I'll report
it. FWIW Debian disables the test suite for powerpc.
https://sources.debian.org/src/binutils/2.36.1-6/debian/rules/#L537

> > (synopsis "Binary utilities: bfd gas gprof ld")
> > (description
> > diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> > index 7c39a84008..f707a01d30 100644
> > --- a/gnu/packages/commencement.scm
> > +++ b/gnu/packages/commencement.scm
> > @@ -2653,7 +2653,22 @@ exec " gcc "/bin/" program
> > #:modules ((guix build gnu-build-system)
> >(guix build utils)
> >(ice-9 ftw)); for 'scandir'
> > +
> > +   ;; #:phases gets modified for powerpc-linux in binutils,
> > +   ;; so #:phases here needs to be after the inherited one.
> > +   ,@(substitute-keyword-arguments (package-arguments binutils)
> > +   ((#:configure-flags cf)
> > +`(cons ,(string-append "--target=" (boot-triplet))
> > +   ,cf)))
> > +
> > #:phases (modify-phases %standard-phases
> > +  ,@(if (string=? (%current-system) "powerpc-linux")
> > +  '((add-after 'unpack 'disable-rust-libiberty-test
> > +  (lambda _
> > +(substitute* "libiberty/testsuite/Makefile.in"
> > +  ((" check-rust-demangle ") ""))
> > +#t)))
> > +  '())
> >(add-after 'install 'add-symlinks
> >  (lambda* (#:key outputs #:allow-other-keys)
> >;; The cross-gcc invokes 'as', 'ld', etc, without the
> > @@ -2667,12 +2682,8 @@ exec " gcc "/bin/" program
> >  (with-directory-excursion (string-append out 
> > "/bin")
> >(for-each (lambda (name)
> >(symlink name (remove-triplet-prefix 
> > name)))
> > -(scandir "." has-triplet-prefix?)))
> > +(scandir "." 
> > has-triplet-prefix?)
> >  
> > -   ,@(substitute-keyword-arguments (package-arguments binutils)
> > -   ((#:configure-flags cf)
> > -`(cons ,(string-append "--target=" (boot-triplet))
> > -   ,cf)
> >  (inputs (%boot0-inputs
> >  
> >  (define libstdc++-boot0
> 
> I think you can put all of this in the substitute-keyword-arguments
> form, which would (1) eliminate the need for a comment, (2) eliminate
> the need to worry about the order of the keyword arguments, and (3)
> eliminate the need to duplicate the new phase in two package
> definitions:
> 
> (define binutils-boot0
>   (package
> (inherit binutils)
> (source (bootstrap-origin (package-source binutils)))
> (name "binutils-cross-boot0")
> (arguments
>  `(#:guile ,%bootstrap-guile
>#:implicit-inputs? #f
> 
>#:modules ((guix build gnu-build-system)
>   (guix build utils)
>   (ice-9 ftw)); for 'scandir'
> 
>,@(substitute-keyword-arguments (package-arguments binutils)
>((#:configure-flags 

Re: [PATCH 0/9] Add 32-bit powerpc support

[Vincent Legoll]

Hi,

On Sat, Apr 17, 2021 at 9:44 PM Efraim Flashner  wrote:
> As far as operating systems with support¹ Adélie Linux is the only
> one I know that's actually targeting the machines.

There's also a void port being worked on, but not
upstreamed yet (https://voidlinux-ppc.org)

gentoo, openbsd & netbsd also still have support too.

-- 
Vincent Legoll

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Chris Marusich]

Efraim Flashner  writes:

> * gnu/packages/base.scm (binutils)[arguments]: Add phase on
> powerpc-linux to adjust the test suite.
> * gnu/packages/commencement.scm (binutils-boot0)[arguments]: Move custom
> phases after inherited arguments. Add phase on powerpc-linux to adjust
> the test suite.

Nits: adjust the test suite to do what?  The message would be clearer if
it explained the purpose of the adjustment.  You could also name the
phases you added/moved, for extra clarity, if you want to.

> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index dbb7c619fe..b9fc0a6e29 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -531,7 +531,16 @@ change.  GNU make offers many powerful extensions over 
> the standard utility.")
>  
>;; Make sure 'ar' and 'ranlib' produce archives in 
> a
>;; deterministic fashion.
> -  "--enable-deterministic-archives")))
> +  "--enable-deterministic-archives")
> +  ,@(if (string=? (%current-system) "powerpc-linux")
> +  `(#:phases
> +(modify-phases %standard-phases
> +  (add-after 'unpack 'disable-rust-libiberty-test
> +(lambda _
> +  (substitute* "libiberty/testsuite/Makefile.in"
> +((" check-rust-demangle ") ""))
> +  #t
> +  '(

What's the problem?  Presumably the test fails; a comment here could
clarify that.

If it's a test failure, has the issue been reported upstream?

> (synopsis "Binary utilities: bfd gas gprof ld")
> (description
> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index 7c39a84008..f707a01d30 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -2653,7 +2653,22 @@ exec " gcc "/bin/" program
> #:modules ((guix build gnu-build-system)
>(guix build utils)
>(ice-9 ftw)); for 'scandir'
> +
> +   ;; #:phases gets modified for powerpc-linux in binutils,
> +   ;; so #:phases here needs to be after the inherited one.
> +   ,@(substitute-keyword-arguments (package-arguments binutils)
> +   ((#:configure-flags cf)
> +`(cons ,(string-append "--target=" (boot-triplet))
> +   ,cf)))
> +
> #:phases (modify-phases %standard-phases
> +  ,@(if (string=? (%current-system) "powerpc-linux")
> +  '((add-after 'unpack 'disable-rust-libiberty-test
> +  (lambda _
> +(substitute* "libiberty/testsuite/Makefile.in"
> +  ((" check-rust-demangle ") ""))
> +#t)))
> +  '())
>(add-after 'install 'add-symlinks
>  (lambda* (#:key outputs #:allow-other-keys)
>;; The cross-gcc invokes 'as', 'ld', etc, without the
> @@ -2667,12 +2682,8 @@ exec " gcc "/bin/" program
>  (with-directory-excursion (string-append out "/bin")
>(for-each (lambda (name)
>(symlink name (remove-triplet-prefix 
> name)))
> -(scandir "." has-triplet-prefix?)))
> +(scandir "." has-triplet-prefix?)
>  
> -   ,@(substitute-keyword-arguments (package-arguments binutils)
> -   ((#:configure-flags cf)
> -`(cons ,(string-append "--target=" (boot-triplet))
> -   ,cf)
>  (inputs (%boot0-inputs
>  
>  (define libstdc++-boot0

I think you can put all of this in the substitute-keyword-arguments
form, which would (1) eliminate the need for a comment, (2) eliminate
the need to worry about the order of the keyword arguments, and (3)
eliminate the need to duplicate the new phase in two package
definitions:

(define binutils-boot0
  (package
(inherit binutils)
(source (bootstrap-origin (package-source binutils)))
(name "binutils-cross-boot0")
(arguments
 `(#:guile ,%bootstrap-guile
   #:implicit-inputs? #f

   #:modules ((guix build gnu-build-system)
  (guix build utils)
  (ice-9 ftw)); for 'scandir'

   ,@(substitute-keyword-arguments (package-arguments binutils)
   ((#:configure-flags cf)
`(cons ,(string-append "--target=" (boot-triplet))
   ,cf))
   ;; The presence of '%standard-phases as the default value here is
   ;; important.  It ensures that even when (package-argument
   ;; binutils) does not already contain the #:phases keyword
   ;; argument, the substitution will occur.  If you omit a default
   ;; value and (package-arguments binutils) does not contain the
   ;; 

Re: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> I haven’t looked into details so I’ll just share thoughts from a
> maintenance viewpoint:
> 
>   1. Those fdisk patch file names will make ‘guix lint’ unhappy.  :-)

I'll make sure to touch them up. I was also not happy about the
supported-architectures field of the package, I took that from Debain
(or was it Gentoo?) but I'm not sure of a technical reason why it can't
be built from other architectures.

>   2. Apart from mac-fdisk-p18.patch, which looks relatively big, the
>  changes seem to be rather non-intrusive, so it’s tempting to merge
>  them (on ‘core-updates’ I guess?).

Before I found some of the patches I played around with fixing the
package. Without looking at the patches too closely some of them fix
warnings and some of them actually make it compile correctly.

>   3. OTOH, what will be the status of this architecture?  I don’t think
>  new 32-bit PPC hardware is being made (right?), so I guess we
>  probably won’t have substitutes for that architecture.  That means
>  it won’t be supported at the same level as other architectures and
>  may quickly suffer from bitrot.

I don't know about new 32-bit powerpc hardware, I think it's only being
newly created for the embedded and networking space. As far as operating
systems with support¹ Adélie Linux is the only one I know that's
actually targeting the machines.

I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is
faster than building on native hardware (1 core, 1.5GB of RAM, original
4200 RPM disk), edging it out on single threaded compiling and doing
great when it comes to using multiple cores and parallel builds.
Ignoring how to create an OS image if we just targeted, say, mesa and
maybe one or two other packages, we could have a core set which doesn't
change regularly and won't take up too much emulated build time but will
save days of compile time.

> I’m torn between #2 and #3.
> 
> What do people think?

The fear of bit-rot is real and I think we should mention in the manual
(when I actually write the section) that support is best-effort with
minimal substitutes.

> Thanks,
> Ludo’.

¹ https://en.wikipedia.org/wiki/PowerPC#Operating_systems_with_native_support

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: [PATCH 0/9] Add 32-bit powerpc support

[Vincent Legoll]

Hi,

On Sat, Apr 17, 2021 at 6:04 PM Ludovic Courtès  wrote:
>   3. OTOH, what will be the status of this architecture?  I don’t think
>  new 32-bit PPC hardware is being made (right?), so I guess we
>  probably won’t have substitutes for that architecture.  That means
>  it won’t be supported at the same level as other architectures and
>  may quickly suffer from bitrot.
>
> I’m torn between #2 and #3.

I don't think we have checked that ppc64 is unable to build this in a
similar way that x86_64 is able to build 32 bit x86 without virtualization.

But that may be possible, so all hope is not lost.

-- 
Vincent Legoll

Re: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-ppc
>
> The wip-ppc branch on Savannah is currently in a good state. With the
> recent rapid churn on core-updates I haven't been very quick about
> rebasing on core-updates but I can confirm that building out to mesa
> works. Building is slow, it took 6 days to build from guile-final to
> mesa without stopping.
>
> The patches start with adding the bootstrap binaries for powerpc.

Woohoo!

>  gnu/build/vm.scm  |1 +
>  gnu/local.mk  |2 +
>  gnu/packages/base.scm |   11 +-
>  gnu/packages/bootstrap.scm|   37 +-
>  gnu/packages/commencement.scm |   21 +-
>  gnu/packages/debug.scm|2 +
>  gnu/packages/disk.scm |   44 +
>  gnu/packages/gl.scm   |   18 +-
>  gnu/packages/guile.scm|   21 +-
>  gnu/packages/nss.scm  |7 +-
>  .../patches/mac-fdisk-gentoo-patchset.patch   |  866 +++
>  gnu/packages/patches/mac-fdisk-p18.patch  | 2070 +
>  gnu/packages/version-control.scm  |6 +-
>  guix/packages.scm |4 +-
>  m4/guix.m4|4 +-
>  15 files changed, 3096 insertions(+), 18 deletions(-)
>  create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
>  create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch

I haven’t looked into details so I’ll just share thoughts from a
maintenance viewpoint:

  1. Those fdisk patch file names will make ‘guix lint’ unhappy.  :-)

  2. Apart from mac-fdisk-p18.patch, which looks relatively big, the
 changes seem to be rather non-intrusive, so it’s tempting to merge
 them (on ‘core-updates’ I guess?).

  3. OTOH, what will be the status of this architecture?  I don’t think
 new 32-bit PPC hardware is being made (right?), so I guess we
 probably won’t have substitutes for that architecture.  That means
 it won’t be supported at the same level as other architectures and
 may quickly suffer from bitrot.

I’m torn between #2 and #3.

What do people think?

Thanks,
Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Chris Marusich]

Efraim Flashner  writes:

> * gnu/packages/debug.scm (american-fuzzy-lop): Add case for
> powerpc-linux.
> (qemu-for-american-fuzzy-lop): Same.
> ---
>  gnu/packages/debug.scm | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gnu/packages/debug.scm b/gnu/packages/debug.scm
> index 2913c348f3..1326ce6e16 100644
> --- a/gnu/packages/debug.scm
> +++ b/gnu/packages/debug.scm
> @@ -179,6 +179,7 @@ tools that process C/C++ code.")
> ("aarch64-linux"  "aarch64")
> ("armhf-linux""arm")
> ("mips64el-linux" "mips64el")
> +   ("powerpc-linux"  "ppc")
> ;; Prevent errors when querying this package on 
> unsupported
> ;; platforms, e.g. when running "guix package --search="
> (_"UNSUPPORTED"
> @@ -254,6 +255,7 @@ down the road.")
> ("aarch64-linux"  "aarch64")
> ("armhf-linux""arm")
> ("mips64el-linux" "mips64el")
> +   ("powerpc-linux"  "ppc")
> ;; Prevent errors when querying this package on 
> unsupported
> ;; platforms, e.g. when running "guix package --search="
> (_"UNSUPPORTED"

LGTM, I see it's in master already like you said.

-- 
Chris


signature.asc
Description: PGP signature

Re: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Wed, Apr 07, 2021 at 10:33:33PM +0200, Vincent Legoll wrote:
> Hello,
> 
> On Tue, Apr 6, 2021 at 2:26 PM Efraim Flashner  wrote:
> > The wip-ppc branch on Savannah is currently in a good state. With the
> > recent rapid churn on core-updates I haven't been very quick about
> > rebasing on core-updates but I can confirm that building out to mesa
> > works. Building is slow, it took 6 days to build from guile-final to
> > mesa without stopping.
> 
> I still haven't dragged my G4 mini from its osx misery, so I tried
> cross-building (from x86_64) instead.
> 
> cross-builds ok:
> * bootstrap-tarballs
> * guile
> * binutils
> * mac-fdisk
> 
> failed:
> * guix (perl refused to cross-build)
> * nss, because nspr failed with:
> [...]
> ../../../config/./nsinstall -R -m 444 ./_aix32.cfg ./_aix64.cfg
> ./_bsdi.cfg ./_darwin.cfg ./_freebsd.cfg ./_hpux32.cfg ./_hpux64.cfg
> ./_linux.cfg ./_netbsd.cfg ./_nto.cfg ./_openbsd.cfg ./_os2.cfg
> ./_qnx.cfg ./_riscos.cfg ./_scoos.cfg ./_solaris.cfg ./_unixware7.cfg
> ./_unixware.cfg ./_win95.cfg ./_winnt.cfg
> ../../../dist/include/nspr/md
> ../../../config/./nsinstall: ../../../config/./nsinstall: cannot
> execute binary file
> 
> mesa and afl refused because of meson-build-system.

There's currently a bug with cross-building on core-updates. I ran into
it while trying to build rust for i686.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: [PATCH 0/9] Add 32-bit powerpc support

[Vincent Legoll]

Hello,

On Tue, Apr 6, 2021 at 2:26 PM Efraim Flashner  wrote:
> The wip-ppc branch on Savannah is currently in a good state. With the
> recent rapid churn on core-updates I haven't been very quick about
> rebasing on core-updates but I can confirm that building out to mesa
> works. Building is slow, it took 6 days to build from guile-final to
> mesa without stopping.

I still haven't dragged my G4 mini from its osx misery, so I tried
cross-building (from x86_64) instead.

cross-builds ok:
* bootstrap-tarballs
* guile
* binutils
* mac-fdisk

failed:
* guix (perl refused to cross-build)
* nss, because nspr failed with:
[...]
../../../config/./nsinstall -R -m 444 ./_aix32.cfg ./_aix64.cfg
./_bsdi.cfg ./_darwin.cfg ./_freebsd.cfg ./_hpux32.cfg ./_hpux64.cfg
./_linux.cfg ./_netbsd.cfg ./_nto.cfg ./_openbsd.cfg ./_os2.cfg
./_qnx.cfg ./_riscos.cfg ./_scoos.cfg ./_solaris.cfg ./_unixware7.cfg
./_unixware.cfg ./_win95.cfg ./_winnt.cfg
../../../dist/include/nspr/md
../../../config/./nsinstall: ../../../config/./nsinstall: cannot
execute binary file

mesa and afl refused because of meson-build-system.

-- 
Vincent Legoll

[PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-ppc

The wip-ppc branch on Savannah is currently in a good state. With the
recent rapid churn on core-updates I haven't been very quick about
rebasing on core-updates but I can confirm that building out to mesa
works. Building is slow, it took 6 days to build from guile-final to
mesa without stopping.

The patches start with adding the bootstrap binaries for powerpc.

The next patch fixes guile-3.0.2+ on powerpc (and probably other 32-bit
big-endian systems) and is the result of almost 3 weeks of bisecting.

Next is a patch for binutils to disable one of the tests. The test is
new to core-updates, and fails on powerpc-linux but not the other
architectures we support.

The mesa patch works, but I have to see about enabling the tests. I have
also tested updating mesa and enabling the llvm backend on aarch64 and
the tests no longer fail there, so I'll do another couple (3 hour) mesa
builds to see if the comment needs adjusting or if the tests can be
enabled on powerpc-linux.

mac-fdisk I didn't have a solid reason to put in the wip-ppc branch but
there it is. I need to change CC=gcc to use cc-for-target.

The patch for american-fuzzy-lop I snuck into master

the qemu-command in gnu/build/vm shouldn't overlap with ppc64le.

the last two patches, disabling the tests for mercurial and nss, can
probably be dropped. The comments are accurate though, and we have done
similar in the past on mips64le and armhf.

Efraim Flashner (9):
  gnu: bootstrap: Add support for powerpc-linux.
  gnu: guile-3.0: Fix building on powerpc-linux.
  gnu: binutils: Adjust test suite on powerpc-linux.
  gnu: mesa: Add support for powerpc-linux.
  gnu: Add mac-fdisk.
  gnu: american-fuzzy-lop: Add support for powerpc-linux.
  build: qemu-command: Add support for powerpc.
  gnu: mercurial: Skip tests on powerpc-linux.
  gnu: nss: Skip tests on powerpc-linux.

 gnu/build/vm.scm  |1 +
 gnu/local.mk  |2 +
 gnu/packages/base.scm |   11 +-
 gnu/packages/bootstrap.scm|   37 +-
 gnu/packages/commencement.scm |   21 +-
 gnu/packages/debug.scm|2 +
 gnu/packages/disk.scm |   44 +
 gnu/packages/gl.scm   |   18 +-
 gnu/packages/guile.scm|   21 +-
 gnu/packages/nss.scm  |7 +-
 .../patches/mac-fdisk-gentoo-patchset.patch   |  866 +++
 gnu/packages/patches/mac-fdisk-p18.patch  | 2070 +
 gnu/packages/version-control.scm  |6 +-
 guix/packages.scm |4 +-
 m4/guix.m4|4 +-
 15 files changed, 3096 insertions(+), 18 deletions(-)
 create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
 create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch


base-commit: f08b070019a3c1697bb0b4a783dcd4f31243715a
-- 
2.31.1