I wrote: > This relies on "nm" being able to work on shlibs, which it's not > required to by POSIX. However, it seems to behave as desired even > on my oldest dinosaurs. In any case, if "nm" doesn't work then > we'll just not detect such problems on that platform, which should > be OK as long as the test does work on common platforms. > Other than that point I think it's relying only on POSIX-spec > features.
Further dinosaur-wrangling reveals a small problem on prairiedog (ancient macOS): $ nm -A -g -u libpq.5.14.dylib | grep abort libpq.5.14.dylib:fe-connect.o: _abort libpq.5.14.dylib:_eprintf.o: _abort The fe-connect.o reference is from PGTHREAD_ERROR of course, but what's that other thing? Investigation finds this: https://opensource.apple.com/source/clang/clang-800.0.38/src/projects/compiler-rt/lib/builtins/eprintf.c.auto.html IOW it seems that this file is pulled in to implement <assert.h>, and the abort call underlies uses of Assert. So that seems fine from a coding-rule perspective: it's okay for development builds to contain core-dumping assertions. It complicates matters for the proposed patch though. As far as old macOS goes, it seems like we can work around this pretty easily, since this version of nm helpfully breaks down the references by .o file: just add a "grep -v" pass to reject "_eprintf.o:". However, if there are any other platforms that similarly convert assert() calls into some direct reference to abort(), it may be harder to work around it elsewhere. I guess the only way to know is to see what the buildfarm says. Worst case, we might only be able to enforce the prohibition against exit(). That'd be annoying but it's still much better than nothing. regards, tom lane
