Arch Linux User Repository

Updated the package to fix some build issues, plus include a thread patch similar to how upstream fixed for SBBS.

ncurses is required by the base group, so that's the only hard requirement. Everything else is now optional (X11/SDL/the "icon" support).

Let me know if you have any issues with the new package.

I fixed this by creating a patch against src/cl/kernel/thread.h to swap pthread_yield to use sched_yield (as is used in other areas). I am not sure if this is 100% equiv but it compiled and I was able to use it for a bit.

--- kernel/thread.h.orig    2022-04-22 10:39:51.040431767 -0600
+++ kernel/thread.h 2022-04-22 10:42:30.564205355 -0600
@@ -3016,7 +3016,7 @@
   #if defined( __linux__ ) && !defined( __USE_GNU )
    void pthread_yield( void );
   #endif /* Present but not prototyped unless GNU extensions are enabled */
-  #define  THREAD_YIELD()          pthread_yield()
+  #define  THREAD_YIELD()          sched_yield()
 #endif /* Not-very-portable Posix portability */
 #define THREAD_SLEEP( ms )         { \
                                                                        struct timeval tv = { 0 }; \

In order to fit this into the build system I added the patch file to 3rdp/build/ as cl-thread-pthread_yield.patch.

I modified 3rdp/build/GNUmakefile in the following ways:

Modified line 70 to include $(3RDP_ROOT)$(DIRSEP)/build/cl-thread-pthread_yield.patch right before | $(CRYPT_SRC) $(CRYPT_IDIR) end.

I added an additional patch line right after the "cl-learn-numbers.patch" line on 114: $(QUIET)patch -p0 -d $(CRYPT_SRC) < cl-thread-pthread_yield.patch

Now if you compile SyncTERM as before it should compile and link. Perhaps the maintainer knows how to wire all this up in an Arch reasonable way?

@rvalles: Yes, it is broken. But its a upstream issue.

There is a ticket about this undefined reference to pthread_yield': https://sourceforge.net/p/syncterm/tickets/77/

But so far, there is no fix.

The ticket is somewhat recent; its from 2022-01-05. Lets hope it gets fixed soon.

Since its an upstream issue, there is nothing I can do about it.

This build seems currently broken.

make[1]: Leaving directory '/home/rvalles/.cache/yay/syncterm/src/syncterm-1.1/src/hash'
Linking gcc.linux.x64.exe.release/syncterm
/usr/bin/ld: /home/rvalles/.cache/yay/syncterm/src/syncterm-1.1/src/../3rdp/gcc.linux.x64.release/cl/libcl.a(sendmsg.o): in function `waitForObject':
sendmsg.c:(.text+0x1096): undefined reference to `pthread_yield'
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:104: gcc.linux.x64.exe.release/syncterm] Error 1

On Manjaro, I just installed it a few days ago. Works fine.

@ekollof Well, I don't know what to tell you. I've just compile it without issues.

wget https://aur.archlinux.org/cgit/aur.git/snapshot/syncterm.tar.gz
tar xzvf syncterm.tar.gz
cd syncterm
makepkg

That's how I compiled it, and it worked fine.

@chris_l

Oops, I also tried building by hand which gave a similar error. This is what I get from yay:

patching file ./tools/ccopts.sh
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 2: syntax error: unexpected end of file
make[1]: *** [GNUmakefile:115: ../build//home/ekollof/.cache/yay/syncterm/src/syncterm-1.1/src/../3rdp/gcc.linux.x64.release/cl/libcl.a] Error 2
make[1]: Leaving directory '/home/ekollof/.cache/yay/syncterm/src/syncterm-1.1/3rdp/build'
make: *** [/home/ekollof/.cache/yay/syncterm/src/syncterm-1.1/src/build/Common.gmake:519: cl] Error 2

@ekollof How are you compiling it?

That path Downloads/unpack/sbbs/3rdp/build looks unusual. It should be something like src/syncterm-1.1/3rdp/build

Compile fails:

patching file ./random/unix.c
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 2: syntax error: unexpected end of file
make[1]: *** [GNUmakefile:138: ../build/../../src/../3rdp/gcc.linux.x64.release/cl/libcl.a] Error 2
make[1]: Leaving directory '/home/ekollof/Downloads/unpack/sbbs/3rdp/build'
make: *** [../build/Common.gmake:521: cl] Error 2

This compiles and runs fine on aarch64 (and presumably other arm variants) so long as both calls to make are preceded with CFLAGS=-D__arm__=1

I imagine a simple check for architecture and branching the make calls would suffice.