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