Re: kern/56353: Build hung

[RVP <rvp%SDF.ORG@localhost>]

The following reply was made to PR kern/56353; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56353: Build hung
Date: Mon, 17 Jan 2022 06:56:41 +0000 (UTC)

 On Sun, 16 Jan 2022, Andreas Gustafsson wrote:
 
 > The build hung on b5 again, in exactly the same place as the last time:
 >
 > 666 4052 4811 36182 72 10 25540 8964 pipe_wr IN ?  0:00.03 | `--
 >   /tmp/build/2022.01.15.17.33.42-i386/tools/lib/gcc/i486--netbsdelf/10.3.0/../../../../i486--netbsdelf/bin/ld
 >   -plugin
 >   /tmp/build/2022.01.15.17.33.42-i386/tools/libexec/gcc/i486--netbsdelf/10.3.0/liblto_plugin.so
 >   -plugin-opt=/tmp/build/2022.01.15.17.33.42-i386/tools/libexec/gcc/i486--netbsdelf/10.3.0/lto-wrapper
 >   -plugin-opt=-fresolution=/tmp/ccTneHhI.res
 >   --sysroot=/tmp/build/2022.01.15.17.33.42-i386/destdir --eh-frame-hdr
 >   -dc -dp -dynamic-linker /usr/libexec/ld.elf_so -o boot.sym
 >   -L/tmp/build/2022.01.15.17.33.42-i386/tools/lib/gcc/i486--netbsdelf/10.3.0
 >   -L/tmp/build/2022.01.15.17.33.42-i386/tools/lib/gcc/i486--netbsdelf/10.3.0/../../../../i486--netbsdelf/lib
 >   -L/tmp/build/2022.01.15.17.33.42-i386/destdir/usr/lib -N -e boot_start
 >   -z relro -Ttext 0 -cref biosboot.o boot2.o conf.o devopen.o exec.o
 >   exec_multiboot1.o exec_multiboot2.o vers.o
 >   /tmp/build/2022.01.15.17.33.42-i386/obj/sys/arch/i386/stand/boot/biosboot/lib/i386/libi386.a
 >   /tmp/build/2022.01.15.17.33.42-i386/obj/sys/arch/i386/stand/boot/biosboot/lib/sa/libsa.a
 >   /tmp/build/2022.01.15.17.33.42-i386/obj/sys/arch/i386/stand/boot/biosboot/lib/z/libz.a
 >   /tmp/build/2022.01.15.17.33.42-i386/obj/sys/arch/i386/stand/boot/biosboot/lib/kern/libkern.a
 >   /tmp/build/2022.01.15.17.33.42-i386/obj/sys/arch/i386/stand/boot/biosboot/lib/i386/libi386.a
 >   /tmp/build/2022.01.15.17.33.42-i386/obj/sys/arch/i386/stand/boot/biosboot/lib/sa/libsa.a
 >
 > And again, attaching to the ld process with gdb and detching unstuck it.
 >
 
 Could this be the issue fixed in PR #56422?
 Is b5 running with that fix?
 
 -RVP