cmake stuck on mips

Hi,

while trying to verify that librsvg builds on my qemu-hosted
NetBSD/mips(el), as part of validating the rust build for this
architecture, I appear to have struck an impasse.

The following dependencies are exposed:

librsvg -> cairo -> meson -> python3.12 -> py-setuptools -> glib2
-> cmake.

And ... my attempt at building cmake is stuck.  If I have
understood correctly, cmake first builds a "bootstrap cmake"
using ordinary "make" (or gmake), and then proceeds to use the
"bootstrap cmake" to build itself.  However, it appears that on
the first attempt at using the "bootstrap cmake" the process gets
stuck in kqueue and makes no progress -- the last few lines of
the build log (excuse the long line, but I already removed most
of the names of the object files, ref. the [...]):

c++ -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lexecinfo -latomic -O2 -I/usr/include -I/usr/pkg/include -I/usr/pkg/include/libxml2 -D_NETBSD_SOURCE    -I/usr/pkg/include  -I/usr/pkg/include     -DCMAKE_BOOTSTRAP    -DCMake_HAVE_CXX_MAKE_UNIQUE=1   -I/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstrap.cmk   -I/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Source   -I/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Source/LexerParser   -I/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Utilities/std   -I/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Utilities  cmAddCompileDefinitionsCommand.o cmAddCustomCommandCommand.o [...] System.o Terminal.o jsoncpp-src-lib_json-json_reader.cpp.o jsoncpp-src-lib_json-json_value.cpp.o jsoncpp-src-lib_json-json_writer.cpp.o  -lkvm -L/usr/pkg/lib -luv -lkvm  -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lrhash  -lcrypto -o cmake
ld: /usr/pkgsrc/devel/cmake/work/.buildlink/lib/libuv.so: warning: warning: reference to compatibility statvfs(); include <sys/statvfs.h> to generate correct reference
loading initial cache file /usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstrap.cmk/InitialCacheFlags.cmake

Some status displays:

mipsel# ps audw
USER   PID %CPU %MEM   VSZ  RSS TTY   STAT STARTED    TIME COMMAND
he   27218  0.0  0.1  9568  484 ttyp0 Is   19Jun25 0:37.39 | |   `-- -csh (tcsh)
he    2160  0.0  0.1  9456  328 ttyp0 I    Sun09AM 0:00.03 | |     |-- -csh (tcsh)
he   19570  0.0  0.1 10228  460 ttyp0 IN   Sun09AM 0:01.42 | |     | `-- make install 
he   24520  0.0  0.1  6832  540 ttyp0 IN   Sun09AM 0:00.04 | |     |   `-- /bin/sh -c set -e;\t\t\t\t\t if test -n "" &&  /usr/sbin
he   18881  0.0  0.1  9220  464 ttyp0 IN   Sun09AM 0:03.03 | |     |     `-- /usr/bin/make _MAKE=/usr/bin/make NATIVE_OPSYS=NetBSD 
he   22314  0.0  0.2 11412  980 ttyp0 IN   Sun09AM 0:09.51 | |     |       `-- /bin/sh bootstrap 
he    6990  0.0  1.6 24756 8464 ttyp0 IN    9:39AM 0:00.71 | |     |         `-- /usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstra
...

with "ww":

he    6990  0.0  1.6 24756 8464 ttyp0 IN    9:39AM 0:00.71 | |     |         `-- /usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstrap.cmk/cmake /usr/pkgsrc/devel/cmake/work/cmake-3.31.7 -C/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstrap.cmk/InitialCacheFlags.cmake -GUnix Makefiles -DCMAKE_BOOTSTRAP=1 -DCMAKE_USE_SYSTEM_LIBRARIES=1 -DCMAKE_USE_SYSTEM_LIBRARY_CPPDAP=0 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 

with "ps axlww":

1000  6990 22314 20480  78  4 24756  8464 kqueue  IN   ttyp0    0:00.71 /usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstrap.cmk/cmake /usr/pkgsrc/devel/cmake/work/cmake-3.31.7 -C/usr/pkgsrc/devel/cmake/work/cmake-3.31.7/Bootstrap.cmk/InitialCacheFlags.cmake -GUnix Makefiles -DCMAKE_BOOTSTRAP=1 -DCMAKE_USE_SYSTEM_LIBRARIES=1 -DCMAKE_USE_SYSTEM_LIBRARY_CPPDAP=0 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 

mipsel# uptime
 4:45PM  up 104 days, 23:29, 2 users, load averages: 0.00, 0.00, 0.00
mipsel# 
mipsel# uname -a
NetBSD mipsel 10.99.10 NetBSD 10.99.10 (MIPSSIM) #8: Mon Dec 25 18:08:12 CET 2023  [email protected]:/u/build/HEAD/obj/evbmips-el/sys/arch/evbmips/compile/MIPSSIM evbmips
mipsel# 
mipsel# gcc --version
gcc (nb3 20231008) 10.5.0
...

:(

Does anyone have any idea what might be going on and how to fix
it?


In a desperate attempt at seeing if the GCC version makes any
difference, I made an attempt at seeing if getting gcc14 built
and using it instead would make any difference, but that attempt
eventually also failed at the end of the gcc14 build:

rm -f stage_current
gmake[3]: Leaving directory '/usr/pkgsrc/lang/gcc14/work/build'
Comparing stages 2 and 3
Bootstrap comparison failure!
isl/isl_test_cpp-isl_test_cpp.o differs
libbacktrace/.libs/dwarf.o differs
libbacktrace/.libs/elf.o differs
libbacktrace/.libs/mmap.o differs
libbacktrace/dwarf.o differs
libbacktrace/elf.o differs
libbacktrace/mmap.o differs
gmake[2]: *** [Makefile:27955: compare] Error 1
gmake[2]: Leaving directory '/usr/pkgsrc/lang/gcc14/work/build'
gmake[1]: *** [Makefile:27935: stage3-bubble] Error 2
gmake[1]: Leaving directory '/usr/pkgsrc/lang/gcc14/work/build'
gmake: *** [Makefile:1103: all] Error 2
*** Error code 2

Stop.
make[1]: stopped in /usr/pkgsrc/lang/gcc14
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/lang/gcc14
515.890u 2707479.311s 774:19:22.21 97.1%        4+0k 17117+109705io 21908530pf+0w


Dang!

And this was after ... going for more than a month.

I passed this under mrg@'s nose, and he commented that it's
probably unlikely that gcc14 for mips in pkgsrc will work, we are
carrying around our own patches for our in-tree compiler which
have evidently not been passed on upstream.  It would have been
nice to not waste so much time...  Is there a particular reason
which makes our mips adaptations unsuitable or unacceptable by
the gcc maintainers?

Regards,

- Håvard