https://gitlab.synchro.net/main/sbbs/-/commit/7941f2308d4f8526b28cb59b
Modified Files:
src/conio/GNUmakefile src/sbbs3/gtkchat/GNUmakefile src/sbbs3/scfg/GNUmakefile src/sbbs3/syncview/GNUmakefile src/sbbs3/targets.mk src/sbbs3/uedit/GNUmakefile src/sbbs3/umonitor/GNUmakefile src/syncterm/GNUmakefile
Log Message:
build: depend on $(HASH_LIB) wherever $(HASH_LIBS) is linked

Every target that links $(HASH_LIBS) needs the hash library to be built
first, but only $(SBBS) and $(JSDOOR) named $(HASH_LIB) as a
prerequisite. $(HASH_LIB) appeared nowhere in targets.mk, so "make sexyz"
(and the other utils, scfg, uedit, umonitor, syncview, gtkchat,
cterm_test and syncterm) never descended into src/hash and simply linked whatever libhash.a happened to be lying around.

That was harmless only because the library's exported surface had not
changed in years. Adding crc32tbl_slicing in boost-4-twins (f7c50ed5e3) introduced the first new symbol, and an incremental build against a
stale libhash.a then failed to link:

zmodem.o: undefined reference to `crc32tbl_slicing'

Dependency (.d) files cannot cover this: they express header-to-object dependencies within one make invocation, not the sub-make descent into src/hash, and the failure is a link-time dependency on a library rather
than a compile-time dependency on a header.

Verified by deleting libhash.a and rebuilding: standalone-utils now
descends into src/hash exactly once and links cleanly, and each of the
other patched makefiles issues the descent as well.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ca2946f39c55712d53a4991f
Modified Files:
src/conio/GNUmakefile src/sbbs3/GNUmakefile src/sbbs3/gtkchat/GNUmakefile src/sbbs3/scfg/GNUmakefile src/sbbs3/syncview/GNUmakefile src/sbbs3/targets.mk src/sbbs3/uedit/GNUmakefile src/sbbs3/umonitor/GNUmakefile src/syncterm/GNUmakefile
Log Message:
build: depend on $(ENCODE_LIB) wherever $(ENCODE_LIBS) is linked

Same gap the previous commit closed for $(HASH_LIB): most targets that
link $(ENCODE_LIBS) never named $(ENCODE_LIB) as a prerequisite, so make
did not descend into src/encode and linked whatever libencode.a was
already on disk. It only ever worked because that library's exported
surface has been stable; the first new symbol added there would break an incremental build exactly the way a stale libhash.a just did.

Covers websrvr, fixsmb, chksmb, smbutil, sbbsecho, addfiles, makeuser, qwknodes, upgrade_to_v319/v320, textgen, scfg, uedit, umonitor,
syncview, gtkchat, cterm_test and syncterm. The targets that already had
the prerequisite (sbbs, node, echocfg, filelist, jsdoor, delfiles,
dupefind) are unchanged.

Verified by deleting libencode.a and libhash.a and rebuilding: make standalone-utils descends into both src/encode and src/hash and links everything cleanly, and each of the other patched makefiles issues the
encode descent as well.

Note that textgen also links $(XPDEV_LIB) by path without depending on
it; that one is left alone here.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net