Possible build issue under NetBSD

[rmaldersoniii]

On a NetBSD system to which I have access, the autogen.sh script hangs in aclocal (repeatable running aclocal interactively) with a prompt "root#"

Has anyone built klh10 under NetBSD before?

[johnsonjh]

OK NetBSD 9.3_STABLE/AMD64 (202308140110Z)

$ git clone https://github.com/PDP-10/klh10 && cd klh10
Cloning into 'klh10'...
remote: Enumerating objects: 1383, done.
remote: Counting objects: 100% (204/204), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 1383 (delta 103), reused 190 (delta 97), pack-reused 1179
Receiving objects: 100% (1383/1383), 2.65 MiB | 2.50 MiB/s, done.
Resolving deltas: 100% (834/834), done.

$ ./autogen.sh 
Not running configure in the source directory.

$ mkdir -p build && ../configure
../configure
checking for gcc... gcc                           
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether make sets $(MAKE)... yes
checking for nanosleep... yes        
[ ... snip ... ]
config.status: creating src/config.h

$ gmake -j 24
[ ... snip ... ]

It's built successfully ...

$ gfind . -executable -type f | xargs
./config.status ./bld-kl/dprpxx ./bld-kl/dpni20 ./bld-kl/wfconv 
./bld-kl/wxtest ./bld-kl/udlconv ./bld-kl/kn10-kl ./bld-kl/uexbconv 
./bld-kl/enaddr ./bld-kl/vdkfmt ./bld-kl/tapedd ./bld-kl/dptm03 
./bld-ks/kn10-ks ./bld-ks/wfconv ./bld-ks/vdkfmt ./bld-ks/wxtest 
./bld-ks/udlconv ./bld-ks/dprpxx ./bld-ks/uexbconv ./bld-ks/enaddr 
./bld-ks/dptm03 ./bld-ks/tapedd ./bld-ks-its/kn10-ks-its ./bld-ks-its/dpimp 
./bld-ks-its/dprpxx ./bld-ks-its/wfconv ./bld-ks-its/wxtest ./bld-ks-its/udlconv 
./bld-ks-its/uexbconv ./bld-ks-its/vdkfmt ./bld-ks-its/dpchaos 
./bld-ks-its/enaddr ./bld-ks-its/dptm03 ./bld-ks-its/tapedd

I have NetBSD 10-CURRENT/ARM64BE here also, I can test if need be.

[Rhialto]

What you're seeing is certainly not expected. I made the configuration stuff on NetBSD. Currently I'm on NetBSD/amd64 9.3. I do get some extra output from aclocal compared to above:

/tmp/klh10$ aclocal
/usr/pkg/share/aclocal/xpk.m4:12: warning: underquoted definition of AM_PATH_XPK
/usr/pkg/share/aclocal/xpk.m4:12:   run info Automake 'Extending aclocal'
/usr/pkg/share/aclocal/xpk.m4:12:   or see https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal

but xpk.m4 is a file that not everybody may have installed. aclocal is from package automake-1.16.5nb3; autoconf and autoheader are from autoconf-2.71nb2.

Call me paranoid, but seeing something that looks like a root prompt suggests something on that system has been backdoored? You could run cat /etc/mtree/set.* | mtree -e -p / to check for modified files, at least those installed by the base system.

[rmaldersoniii]

What does the suggested command string tell me?

I am attempting to debug something unrelated, for which I need a copy of klh10. I'm not particularly interested in becoming a BSD internals wizard...

[larsbrinkhoff]

root# looks like you ended up in a root shell. If you started the build as a normal user, that would be disconcerting, and cause for reinstalling the machine. Or maybe you ran the build as root.

/usr/pkg/share/aclocal/xpk.m4:12: warning: underquoted definition of AM_PATH_XPK looks like a problem with the NetBSD supplied aclocal using a syntax not expected by m4. Is it possible to update aclocal and/or m4 to newer versions?

[Rhialto]

The message about /usr/pkg/share/aclocal/xpk.m4 is a red herring. That file belongs to the totally unrelated package xpk-0.1.4nb1. If you don't have it installed, or when I deinstall it, autogen (aclocal) is silent:

/tmp/klh10$ sudo pkg_delete xpk
/tmp/klh10$ ./autogen.sh 
Not running configure in the source directory.
/tmp/klh10$

When the xpk package was created, aclocal likely didn't check as much as it does today and so its author wasn't aware of any potential issues with it.

What's still unclear to me from the initial report, is if aclocal indeed hangs (i.e. shows no output, doesn't accept input, and doesn't terminate) or if it starts a subshell that looks like / is a root shell. Or if the build was run as root, and the prompt simply indicates that aclocal finished. No output is perfectly fine for aclocal.

[rmaldersoniii]

The NetBSD system in question is not mine to update; it was simply the simplest way to look into a possible issue in the SimH based KL-10 simulation. Used a different path to look into that.

The issue is still a possible problem, because the folks at the system I borrowed will probably want to switch over. I'll ask them to update the build tools.

aclocal is not kicking off a root shell; anything typed at the "root#" prompt is simply echoed, but a newline does not have any effect, nor does ^D or ^C. I can only get out of it via ^Z (followed by a "kill -9" for cleanup).

[Rhialto]

That is indeed a weird symptom, and doesn't sound like anything familiar. So it would be quite impossible to debug remotely. I propose to simply not try, and let the owner of the system reinstall stuff. With that I'll close the ticket then.