Port-mips archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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 he%xxxxxxx.no@localhost:/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
Home |
Main Index |
Thread Index |
Old Index