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
