open https://gitlab.synchro.net/main/sbbs/-/issues/685

I was successfully able to build Synchronet on Debian Linux 12 aarch64 (arm64). The configuration command ``scfg`` works, but ``sbbs`` fails with either ``segmentation fault`` (when run without sudo permission), or ``permission denied to ctrl/*`` when run as sudo. This same behavior is observed even when all server ports are changed to non-privileged ports (like ``2323``, etc). It is also observed on the tag sbbs319b.

```
debianlinuxexp% uname -a
Linux debianlinuxexp 6.1.0-16-arm64 #1 SMP Debian 6.1.67-1 (2023-12-12) aarch64 GNU/Linux
```

1) Log for segfault (when run as non-root):
```
% SBBSCTRL=/home/aackmann/sbbs/ctrl SBBSEXEC=/home/aackmann/sbbs/exec XDG_RUNTIME_DIR=/home/aackmann/.cache/sbbs /home/aackmann/sbbs/exec/sbbs

Synchronet Console for Linux-armv8 Version 3.20a Copyright 2022 Rob Swindell

Reading /home/aackmann/sbbs/ctrl/sbbs.ini
Loading configuration files from /home/aackmann/sbbs/ctrl
!Started as non-root user (id 1000): May fail to bind TCP/UDP ports below 1024 12/19 10:42:37 term Synchronet Terminal Server Version 3.20a
12/19 10:42:37 term Compiled master/ded39adbd Dec 19 2023 08:10:52 with GCC 12.2.0
12/19 10:42:37 term Initializing on Tue Dec 19 10:42:37 2023 with options: 1022 12/19 10:42:37 term Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:42:37 web Synchronet Web Server Version 3.20a
12/19 10:42:37 web Compiled master/ded39adbd Dec 19 2023 08:11:29 with GCC 12.2.0
12/19 10:42:37 web Initializing on Tue Dec 19 10:42:37 2023 with options: 8a0 12/19 10:42:37 web Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:42:37 term Verifying/creating data directories
12/19 10:42:37 term Verifying/creating node directories
12/19 10:42:37 term Telnet Server listening on socket 0.0.0.0 port 2323
12/19 10:42:37 term Telnet Server listening on socket :: port 2323
12/19 10:42:37 term RLogin Server listening on socket 0.0.0.0 port 2325
12/19 10:42:37 term RLogin Server listening on socket :: port 2325
12/19 10:42:37 term SSH Server listening on socket 0.0.0.0 port 2324
12/19 10:42:37 term SSH Server listening on socket :: port 2324
12/19 10:42:37 web Web Server listening on socket 0.0.0.0 port 2400
12/19 10:42:37 web Web Server listening on socket :: port 2400
12/19 10:42:37 web Secure Web Server listening on socket 0.0.0.0 port 2401 12/19 10:42:37 evnt BBS Events BBS Events thread started
12/19 10:42:37 web Secure Web Server listening on socket :: port 2401
12/19 10:42:37 web Web Server thread started
12/19 10:42:37 term Node 1 local spy using socket /home/aackmann/.cache/sbbs/localspy1.sock
[Threads: 6 Sockets: 10 Clients: 0 Served: 0 Errors: 0] (?=Help): zsh: segmentation fault SBBSCTRL=/home/aackmann/sbbs/ctrl SBBSEXEC=/home/aackmann/sbbs/exec =
```
2) Permission issues when run as sudo:
```
% SBBSCTRL=/home/aackmann/sbbs/ctrl SBBSEXEC=/home/aackmann/sbbs/exec XDG_RUNTIME_DIR=/home/aackmann/.cache/sbbs sudo -E /home/aackmann/sbbs/exec/sbbs
[sudo] password for aackmann:

Synchronet Console for Linux-armv8 Version 3.20a Copyright 2022 Rob Swindell

Reading /home/aackmann/sbbs/ctrl/sbbs.ini
Loading configuration files from /home/aackmann/sbbs/ctrl
Current usr ids: ruid - 0, euid - 0, suid - 0
Current grp ids: rgid - 0, egid - 0, sgid - 0
The process 11317 was given capabilities =ep
Setting initial privileges
No password name for:
Successfully changed user-id to
Setting minimum privileges
Current usr ids: ruid - 0, euid - 0, suid - 0
Current grp ids: rgid - 0, egid - 0, sgid - 0
The process 11317 was given capabilities cap_net_bind_service,cap_sys_resource=ep
WARNING: No user account specified, running as root!
12/19 10:45:37 web Synchronet Web Server Version 3.20a
12/19 10:45:37 web Compiled master/ded39adbd Dec 19 2023 08:11:29 with GCC 12.2.0
12/19 10:45:37 web Initializing on Tue Dec 19 10:45:37 2023 with options: 8a0 12/19 10:45:37 term Synchronet Terminal Server Version 3.20a
12/19 10:45:37 term Compiled master/ded39adbd Dec 19 2023 08:10:52 with GCC 12.2.0
12/19 10:45:37 term Initializing on Tue Dec 19 10:45:37 2023 with options: 1022 12/19 10:45:42 web !ERROR 13 (Permission denied) changing directory to: /home/aackmann/sbbs/ctrl
12/19 10:45:42 web Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:45:42 term !ERROR 13 (Permission denied) changing directory to: /home/aackmann/sbbs/ctrl
12/19 10:45:42 term Loading configuration files from /home/aackmann/sbbs/ctrl 12/19 10:45:52 term !ERROR 13 (Permission denied) opening /home/aackmann/sbbs/ctrl/main.ini
12/19 10:45:57 web !ERROR 13 (Permission denied) opening /home/aackmann/sbbs/ctrl/msgs.ini
12/19 10:45:57 term !FAILED to load configuration files
12/19 10:45:57 term Terminal Server thread terminating
12/19 10:45:57 term Terminal Server thread terminated (0 clients served)
12/19 10:46:02 web !FAILED to load configuration files
12/19 10:46:02 web #### Web Server thread terminated (0 clients served, 0 concurrently)
[Threads: 2 Sockets: 0 Clients: 0 Served: 0 Errors: 6] (?=Help): q
```
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4566

For the first issue (segfault), can you provide a backtrace following this how-to guidehttps://wiki.synchro.net/howto:gdb ?

For the second issue (please file as separate issues in the future), who owns the files in question and what are the permission modes on those file? This doesn't seem like an sbbs issue on the surface.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4567

@rswindell Sure, here's the gdb output I could capture:

[gdb_no_threadapplyallbt.txt](/uploads/4853285e094cd9e5fc56ed9dd6f35e7c/gdb_no_threadapplyallbt.txt)

[gdb_with_threadapplyallbt.txt](/uploads/d56989934d69788062b0c20ea5e12d82/gdb_with_threadapplyallbt.txt)

Ok, I don't see the permission issue on another VM. Will investigate what's the problem, even though all files are aackmann:aackmann in that directory. One thing that was different while building it was that your installer hadn't asked me for a password for setcap. So on the failing machine, when I ran make it was already built with sudo permissions. The machine on which it doesn't fail, the make install command stopped for me to enter the password.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4568

According to that backtrace, it's crashing in /lib/libmozjs185.so.1.0

Can you try building/using the libmozjs from the source provided in the sbbs repo instead? It's been patched (by someone) to build for arm64 and presumably was tested: https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/build/js-config.guess.patch?ref_type=heads
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4569

@rswindell It isn't clear how to build it build https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/dist/libmozjs.tgz, and how to apply https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/build/js-config.guess.patch?ref_type=heads to that...

Here's a screenshot that shows all file paths matching "mozjs" in your repo. Is there a make flag, build script, or instructions to build this? (this [documentation](https://firefox-source-docs.mozilla.org/js/build.html) from Mozilla isn't clear) Also it isn't clear if the patches were already applied to produce https://gitlab.synchro.net/main/sbbs/-/blob/master/3rdp/dist/libmozjs.tgz.

--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4570

Building/using the libmozjs from the sbbs git repo is the *default* build behavior. According to the backtrace you supplied, your sbbs is linking with/using `/lib/libmozjs185.so.1.0`, so that implies you're not doing the default thing.

Likely, you're specifying JSLIB and JSINCLUDE options on your make command-line (as instructed to do on https://wiki.synchro.net/howto:raspbian_install) - just removing those 2 options from your make command-line should force the build to compile and link with the libmozjs included in the repo. The patches are applied automatically.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4571

@rswindell Now I get config.status error. Since it seems to have been patched (see the files "config.guess" files below), I am not sure what to do to them... My system is a aarch64 linux (non raspberry pi).


```
repo/3rdp/build/js-config.guess.patch repo/3rdp/src/mozjs/js-1.8.5/js/src/build/autoconf/config.guess.orig repo/3rdp/src/mozjs/js-1.8.5/js/src/build/autoconf/config.guess repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi/config.guess
```

Please check the errors below:

```
$ SBBSEXEC=/home/aackmann/sbbs/exec make install SYMLINK=1
...
creating Makefile
creating shell/Makefile
creating lirasm/Makefile
creating jsapi-tests/Makefile
creating tests/Makefile
creating config/Makefile
creating config/mkdepend/Makefile
creating editline/Makefile
updating cache ./config.cache
creating ./config.status
creating config/autoconf.mk
creating js-config.h
invoking make to create js-config script
gmake[3]: Entering directory '/home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src'
rm -f js-config.tmp
sed < js-config.in > js-config.tmp \
-e 's|@prefix@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs|' \
-e 's|@exec_prefix@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs|' \
-e 's|@includedir@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/include|' \
-e 's|@libdir@|/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/lib|' \
-e 's|@MOZILLA_VERSION@||' \
-e 's|@LIBRARY_NAME@|mozjs185|' \
-e 's|@NSPR_CFLAGS@|-I/usr/include/nspr|' \
-e 's|@JS_CONFIG_LIBS@|-Wl,--whole-archive ctypes/libffi/.libs/libffi.a -Wl,--no-whole-archive -L/usr/lib/aarch64-linux-gnu -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lm -ldl |' \
-e 's|@MOZ_JS_LIBS@|-L/home/aackmann/sbbs/repo/3rdp/build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/lib -lmozjs185|' \
&& mv js-config.tmp js-config && chmod +x js-config
gmake[3]: Leaving directory '/home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src'
configuring in ctypes/libffi
running /bin/sh ./configure --disable-shared --enable-static --disable-raw-api --with-pic --cache-file=/home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi/config.cache --srcdir=.
configure: creating cache /home/aackmann/sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi/config.cache
checking build system type... ./config.guess: unable to guess system type

This script, last modified 2009-11-19, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed information to handle your system.

config.guess timestamp = 2009-11-19

uname -m = aarch64
uname -r = 6.1.0-16-arm64
uname -s = Linux
uname -v = #1 SMP Debian 6.1.67-1 (2023-12-12)

/usr/bin/uname -p = unknown
/bin/uname -X =

hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch = aarch64
/usr/bin/oslevel =
/usr/convex/getsysinfo =

UNAME_MACHINE = aarch64
UNAME_RELEASE = 6.1.0-16-arm64
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP Debian 6.1.67-1 (2023-12-12)
configure: error: cannot guess build type; you must specify one
configure: error: ./configure failed for ctypes/libffi
make[2]: *** [GNUmakefile:77: ../build/../../src/../3rdp/gcc.linux.aarch64.release/mozjs/lib/libmozjs185-1.0.a] Error 1
make[2]: Leaving directory '/home/aackmann/sbbs/repo/3rdp/build'
make[1]: *** [/home/aackmann/sbbs/repo/src/sbbs3/../build/Common.gmake:553: js] Error 2
make[1]: Leaving directory '/home/aackmann/sbbs/repo/src/sbbs3'
make: *** [GNUmakefile:152: sbbs3] Error 2
```
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4574

From the error, it looks like a problem with build/using libffi (e.g. "`configuring in ctypes/libffi`). If you install the appropriate libffi package for your platform (as shown on https://wiki.synchro.net/howto:raspbian_install), perhaps you can avoid that build/problem?

If that doesn't work, perhaps the `js/src/ctypes/libffi/config.guess` will need similar patch as was done for `js/src/build/autoconf/config.guess`.

Someday (not soon), we'll upgrade to a newer libmozjs and not have so many aarch64 issues.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4586

@rswindell I have libffi, and libmozjs installed on my system. I don't know what make variable to use to nudge GNUmakefile to pick system libffi but your packaged libmozjs. How to do that? I had installed all the 3 packages mentioned on rasping_install page on my Debian machine. Not from the same links though, as those are armhf libraries, whereas I have arm64 architecture. Also it was a pain to find mozjs185, as most links were marked deprecated, deleted, etc. My system has libffi.so.6.0.4, and libffi.so.8.1.2.

```
debianlinuxexp% ls -lrta /usr/lib/libffi*
-rw-r--r-- 1 root root 68000 Dec 22 05:08 /usr/lib/libffi.so.8.1.2
-rw-r--r-- 1 root root 68000 Dec 22 05:08 /usr/lib/libffi.so.8
-rw-r--r-- 1 root root 31016 Dec 22 05:08 /usr/lib/libffi.so.6.0.4
-rw-r--r-- 1 root root 31016 Dec 22 05:08 /usr/lib/libffi.so.6
-rw-r--r-- 1 root root 68000 Dec 22 05:08 /usr/lib/libffi.so
-rw-r--r-- 1 root root 49334 Dec 22 05:08 /usr/lib/libffi_pic.a
-rw-r--r-- 1 root root 49638 Dec 22 05:08 /usr/lib/libffi.a
```
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4611

I would like to offer testing support for making macOS client /Linux BBS client/server experience much better

Synchronet doesn't currently support macOS, but SyncTERM does, but since most of us don't own modern Macs, it's kind of a pain. Deuce (main maintainer of SyncTERM) could probably use a modern macOS build/test system, if you can offer him remote access.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs binary: Debian Linux AARCH64 sigfault or permission denied
By: Rob Swindell to GitLab note in main/sbbs on Tue Dec 26 2023 04:52 pm

Howdy,

Synchronet doesn't currently support macOS, but SyncTERM does, but since most of us don't own modern Macs, it's kind of a pain. Deuce (main maintainer of SyncTERM) could probably use a modern macOS build/test system, if you can offer him remote access.

I've offered in the past, and happy to offer again, although it might not be useful.

I can run a gitlab-ci agent on a MAC m1 machine (it'll be inside docker, which I guess is technically linux aarch64) - that can run jobs...

If you need macOS, if there is a way that it can be jailed to a VM on my M1, then I'm happy to take a look.

(I used to run VMs on an Intel mac with VMware, but there is little information about running on M1. That said, I just found this...https://github.com/KhaosT/MacVM).


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4613

If you update config.guess and config.sub in /sbbs/repo/3rdp/src/mozjs/js-1.8.5/js/src/ctypes/libffi with the latest version then you get this error:

configure: error: "libffi has not been ported to aarch64-unknown-linux-gnu." configure: error: ./configure failed for ctypes/libffi

Considering the aarch64 architecture uses arm64 packages, we should be able to force it to build for that.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_4614

I built libmoz locally from the launchpad sources and the debian patches and still get the coredump but there's more information in the bt.

https://pastebin.com/GBnpfz6X
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)