https://gitlab.synchro.net/main/sbbs/-/commit/e009a5e9ae6f0ab75b933adf
Modified Files:
src/build/Common.gmake
Log Message:
Don't leak a parent make's CFLAGS into recursive sub-makes
If CFLAGS is set in the calling environment, GNU make re-exports it to sub-makes with whatever value the makefile has since given it. So
sbbs3's CFLAGS -- which legitimately carries -DLINK_LIST_THREADSAFE via XPDEV-MT_CFLAGS -- reached the "make -C ../xpdev lib" sub-make and
compiled xpdev's *single-threaded* link_list.o with the thread-safe code
paths enabled. That object then referenced sem_trywait_block() and pthread_mutex_initializer_np(), which are only ever built into
libxpdev_mt.a, so every utility that links plain -lxpdev (sbbsecho,
smbutil, chksmb, fixsmb, addfiles, node, ...) failed to link:
ld: xpdev/.../libxpdev.a(link_list.o): in function `listSemTryWaitBlock':
link_list.c: undefined reference to `sem_trywait_block'
ld: xpdev/.../libxpdev.a(link_list.o): in function `listInit':
link_list.c: undefined reference to `pthread_mutex_initializer_np'
Every sub-project includes build/Common.gmake and derives its own flags
from it, so inheriting the parent's was never intended -- the leaked
command line also arrived with duplicated -O3/-O2 and a doubled -D_FORTIFY_SOURCE. Mark the flag variables unexport so a recursive make
always starts from a clean slate.
Reported against Debian trixie, but not specific to it: reproduced (and
the fix verified) on bookworm/gcc-12 simply by putting CFLAGS in the environment.
Co-Authored-By: Claude Opus 4.8 (1M context) <
noreply@anthropic.com>
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net