port-m68k/60278: cmake fails to build on virt68k

["he%NetBSD.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60278
>Category:       port-m68k
>Synopsis:       cmake fails to build on virt68k
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-m68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 17 16:25:01 +0000 2026
>Originator:     Havard Eidnes
>Release:        NetBSD 11.99.5 (of Feb 10 2026)
>Organization:
	I try
>Environment:
System: NetBSD virt68k.urc.uninett.no 11.99.5 NetBSD 11.99.5 (GENERIC) #2: Tue Feb 10 13:25:59 CET 2026  he%mt.urc.uninett.no@localhost:/u/build/HEAD/obj/virt68k/sys/arch/virt68k/compile/GENERIC virt68k
Architecture: m68k
Machine: virt68k
>Description:
	On my path of "trying to do the impossible" (get rust to
	run natively on m68k), I have realized there are a few
	stumbling blocks on that path which prevents progress:
	neither cmake or clang are part of the binary packages
	for this platform.

	And the reason 'cmake' isn't there is that it fails to
	build on m68k.

	The 'cmake' build process is to first build a "bootstrap cmake",
	and then use it to build a full version of itself.

	On m68k the "bootstrap cmake" fails to run, aborting because it
	thinks it is exhausting its stack:

[1]   Abort trap (core dumped) "${cmake_bootstrap_dir}/cmake" "${cmake_source...
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
*** Error code 11

	Turning gdb loose on it reveals among other things:

virt68k: {7} find work -type f \( -name cmake -o -name cmake.core \)
work/cmake-4.3.2/Auxiliary/bash-completion/cmake
work/cmake-4.3.2/Bootstrap.cmk/cmake
work/cmake-4.3.2/cmake.core
virt68k: {8} gdb work/cmake-4.3.2/Bootstrap.cmk/cmake work/cmake-4.3.2/cmake.core
GNU gdb (GDB) 16.3
...
Reading symbols from work/cmake-4.3.2/Bootstrap.cmk/cmake...
[New process 3365]
Core was generated by `cmake'.
Program terminated with signal SIGABRT, Aborted.
#0  0x04e593b4 in _lwp_kill () from /usr/lib/libc.so.12
(gdb) where
#0  0x04e593b4 in _lwp_kill () from /usr/lib/libc.so.12
#1  0x04e59362 in raise () from /usr/lib/libc.so.12
#2  0x04e3bf18 in ?? () from /usr/lib/libc.so.12
#3  0x04e3bf3a in __stack_chk_fail () from /usr/lib/libc.so.12
#4  0x003e7134 in _GLOBAL__sub_I_cmStdIoTerminal.cxx(void) ()
    at /usr/pkgsrc/devel/cmake/work/cmake-4.3.2/Source/cmStdIoTerminal.cxx:182
#5  0x00060e04 in ___start ()
#6  0x00060cba in _start ()
(gdb)

	This is built with this diff to cmake's Makefile applied:

Index: Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/devel/cmake/Makefile,v
retrieving revision 1.239
diff -u -r1.239 Makefile
--- Makefile    26 Mar 2026 09:00:32 -0000      1.239
+++ Makefile    17 May 2026 16:10:32 -0000
@@ -46,6 +46,13 @@
 # for Source/cmDependsJavaParser.cxx
 UNLIMIT_RESOURCES=     datasize
 
+# in an attempt at fixing this for NetBSD/m68k:
+UNLIMIT_RESOURCES=     stacksize
+
+# Debug for m68k...
+CFLAGS+=       -g
+CXXFLAGS+=     -g
+
 # as of 2.4.6, x11 and fortran tests fail in pkgsrc
 TEST_TARGET=           test

	First the stacksize to see if we're bumping into the default
	limit, but the above doesn't help.  '-g' to get more debug
	symbols.

(gdb) l
175
176     void Print(OStream& os, TermAttrSet const& attrs, cm::string_view s)
177     {
178       Print(os, attrs, [s](std::ostream& o) { o << s; });
179     }
180
181     }
182     }
(gdb)

	and disassembly of that function shows that it did indeed
	call the "failed stack overflow test" function:

   0x3e712a <_GLOBAL__sub_I_cmStdIoTerminal.cxx(void)+382>:     cmpl %d1,%d0
   0x3e712c <_GLOBAL__sub_I_cmStdIoTerminal.cxx(void)+384>:     beqs 0x3e7134 <_GLOBAL__sub_I_cmStdIoTerminal.cxx(void)+392>
   0x3e712e <_GLOBAL__sub_I_cmStdIoTerminal.cxx(void)+386>:     bsrl 0x5ff18 <__stack_chk_fail@plt>
=> 0x3e7134 <_GLOBAL__sub_I_cmStdIoTerminal.cxx(void)+392>:     moveml %sp@+,%d2/%a2/%a5

	And the registers when having this function as the current one:

(gdb) i reg
d0             0x0                 0
d1             0x1990aa5f          428911199
d2             0x5f8960            6261088
d3             0x0                 0
d4             0x0                 0
d5             0x0                 0
d6             0x0                 0
d7             0x0                 0
a0             0x0                 0x0
a1             0x4f05c90           0x4f05c90 <__stack_chk_guard>
a2             0x4f05c90           0x4f05c90 <__stack_chk_guard>
a3             0xffeffff0          0xffeffff0
a4             0x5fbf40            0x5fbf40 <environ>
a5             0x5e1504            0x5e1504
fp             0x0                 0x0
sp             0xffefe8d0          0xffefe8d0
ps             0x0                 [ ]
pc             0x3e7134            0x3e7134 <_GLOBAL__sub_I_cmStdIoTerminal.cxx(void)+392>
fpcontrol      <unavailable>
fpstatus       <unavailable>
fpiaddr        <unavailable>
(gdb) 

	So ... %sp isn't really excessive at this point, so .. why does
	the check trigger?

	This is a slightly dated snapshot, so has:

virt68k: {16} gcc --version
gcc (nb2 20260119) 12.5.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

virt68k: {17} 

	but -current appears to have the same version.

	But at this point my ability to debug C++ programs using gdb comes
	up short.

>How-To-Repeat:
	Try to build 'cmake' on m68k, watch it fail.

>Fix:
	Wouldn't that be nice!