From: George Koehler <kernigh@gmail.com>
Subject: Re: powerpc64 bulk build report
To: Stuart Henderson <stu@spacehopper.org>
Cc: ports@openbsd.org
Date: Sat, 23 Mar 2024 23:27:28 -0400

On Fri, 22 Mar 2024 12:03:42 +0000
Stuart Henderson <stu@spacehopper.org> wrote:

> summarising these:

Thanks for taking a look.  I rarely make bulks on powerpc64, because
they tend to hang or panic the powerpc64 kernel, which forces me to
reboot.  This bulk had 2 forced reboots.

> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/databases/mdbtools.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/security/py-keyring,python3.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/databases/postgresql-odbc.log
> 
> Some DPB oddities here. Various "Dependency check failed" and a
> "/usr/sbin/pkg_add -aI -Drepair postgresql-client-16.2 stub_name" /
> "Can't find stub_name" in postgresql-odbc.

"Dependency check failed" might happen after pkg_add failed to add a
dependency.  These errors don't get my attention, because they don't
force me to reboot.  The failure of security/py-keyring,python3 is
most odd, because dpb had packaged py3-keyring-23.6.0p2, then failed
a 2nd build of the same port (as if dpb forgot the existing package).

> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/arm-none-eabi/gcc,aarch64.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/riscv-elf/gcc.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/xtensa-esp32s2-elf/gcc-bootstrap.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/xtensa-esp32s3-elf/gcc-bootstrap.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/xtensa-lx106-elf/gcc-bootstrap.log
> 
> ppc64-specific patches are broken/missing.

patch-gcc_tree-vect-loop_c from lang/gcc/{8,11} might fix the vec_step
problem in all these gcc ports (including riscv32 below).  I will put
BROKEN-powerpc64 on these until I or another powerpc64 user finds time
to fix them.

> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/bullet.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/riscv32-esp-elf/gcc-bootstrap.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/emulators/mednafen.log
> 
> compile error in ppc64-specific code.
> 
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/objfw.log
> 
> relocation problems

The relocations in lookup-asm-powerpc64-elf.S look correct to me, but
lld might not be able to do them.  It might be easier (for me) to
patch the .S than to fix lld.

> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/devel/py-thrift,python3.log
> 
> doesn't produce compiled extension on ppc64.

py-thrift has invalid C code on all big-endian platforms, so it can't
build its C extension.  Back in February 2023, I wrote a potential fix
at https://github.com/apache/thrift/pull/2754 but I got stuck, unable
to post to their bug tracker.  I put my diff in one of my ports trees,
but never shared the ports diff.

> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/editors/emacs,no_x11.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/sysutils/borgmatic.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/textproc/apertium-dicts/eo-fr.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/textproc/apertium-dicts/br-fr.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/textproc/apertium-dicts/eo-en.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/textproc/apertium-dicts/hbs-slv.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/math/lean.log
> 
> segfault during build

Nobody can use gdb to debug these segfaults, because ports/devel/gdb
segfaults at runtime.  I learned that gdb uses C++ exceptions, and all
such exceptions segfault on powerpc64.  I began trying to fix it in
base llvm/libunwind, but the fix is not ready.

> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/lang/gambit.log
> 
> ICE
> 
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/lang/racket-minimal.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/math/gbc.log
> > http://build-failures.rhaalovely.net/powerpc64/2024-03-18/security/distorm3.log
> 
> various errors

racket and distorm3 fail the same way on powerpc, but gbc's failure is
unique to powerpc64.  In gbc, the output of "./fbc ... >libmath.h" is
wrong, only 2 bytes.  I want to debug ./fbc with gdb, but that must
wait until I have a working gdb.

--gkoehler