=?iso-8859-1?Q?J=F6rg?= Westheide <joerg.westheide@sparkpost.com> writes:
> When doing a "make check" on Mac OS X with SIP (aka rootless mode)
> enabled it will fail like this:
> ...
Yeah, well-known problem. AFAIK, all PG developers who use Macs just
disable SIP immediately.
> The problem is that the psql links to libpq which it cannot find (at
> least not the one from the postgres you're building). The usual
> approach to set an environment variable pointing to the correct
> location (DYLD_LIBRARY_PATH on Mac OS X/darwin, see above) does not
> work since Apple's SIP prevents it from getting passed to psql
Yup. This is incredibly brain-damaged and unnecessary on Apple's
part. Several of us have filed bugs about it, and generally not
gotten much response. Perhaps if people keep complaining, though,
eventually they'll see the light.
> What I do in the attached patch is changing the install name of libpq
> in the psql binary of the temp install (used by "make check") to point
> to libpq of the temp install so the (correct) lib is found.
Cute idea, but AFAICS it would at most fix "make check" and not any
tests that required other executables, or libraries besides libpq.
Plus there's the objection that then you're not really testing the
binary you intend to deploy. I suppose if we got invasive enough,
we could extend this concept to every trouble spot, but I don't
much want to go there.
IIRC, the fact that SIP loses DYLD_LIBRARY_PATH is sort of accidental.
It's not that they've broken the variable altogether, it's that when
we invoke the shell to invoke psql, they clear out DYLD_LIBRARY_PATH
because of some weird decision that the shell is a security-critical
program. (As if the ability to invoke a shell with your choice of input
didn't already give you the chance to do, far more easily, anything you
might do by subverting the shell internally.) So it might be possible to
dodge this problem, at least for "make check" and other pg_regress-driven
cases, by changing pg_regress to avoid going through system(3) but
rather fork-and-exec'ing psql directly.
Nobody's pursued that idea, in part because we've generally found
that SIP breaks enough other stuff that you have to keep it turned
off anyway on development machines. But if you're interested,
you could have a look at how messy that would be.
regards, tom lane