Re: macOS SIP, next try

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> See also https://www.postgresql.org/message-id/flat/18012hGLG6HJ9pQDkHAMYuwQKg%40sparkpost.com

Yeah. As I recall from that thread and prior ones, the bottleneck is
really just /bin/sh: something, either the kernel or sh itself, is
clearing out DYLD_LIBRARY_PATH when a shell script starts. (Since
PATH is not reset at the same time, this seems the height of
stupidity/uselessness; but I digress.) But if "make" has a setting
for that variable, the setting *is* successfully passed down to
executed programs. Which implies that make doesn't use the shell while
running stuff, which seems odd. But it gives us a possible escape
hatch.

I experimented a bit, and found that the attached very-quick-hack
patch is enough to get through "make check" and also the isolation
tests. Unsurprisingly, none of the TAP tests work. I experimented
a bit and it looks like "prove" may be failing to pass down
DYLD_LIBRARY_PATH to the test scripts, which would be annoying but
could be worked around (say, by getting TestLib.pm to pull the
value from somewhere).

Based on what I've got here, this avenue probably ends up messier
and more invasive than the install_name_tool avenue, since we'd
likely have to teach quite a few places about explicitly passing
down DYLD_LIBRARY_PATH. It does have the advantage that "make
check" doesn't have to test executables that are different from
the bits we'll really install; but that's probably not worth all
that much. Unless someone can think of a cute way to centralize
the changes some more, I'm inclined to think this isn't the way
forward. But it seemed worth posting the results anyway.

regards, tom lane