From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Samuel Cochran <sj26(at)sj26(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Strange OSX make check-world failure |
Date: | 2018-12-07 06:26:58 |
Message-ID: | 17403.1544164018@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Samuel Cochran <sj26(at)sj26(dot)com> writes:
> System Integrity Protection strips dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, during exec(2) [1]
Yeah. I wish Apple would just fix that silliness ... I'll spare you the
rant about why it's stupid, but it is. (BTW, last I looked, it's not
exec(2) per se that's doing the damage; the problem is that we're
invoking a sub-shell that's considered a protected program for some
reason, and it's only the use of that that causes DYLD_LIBRARY_PATH
to get removed from the process environment.)
> so we need to rewrite the load paths inside binaries when relocating then during make temp-install before make check on darwin.
Interesting proposal, but I think it needs work.
* As coded, this only fixes the problem for references to libpq, not
any of our other shared libraries.
* It's also unpleasant that it hard-wires knowledge of libpq's version
numbering in a place pretty far removed from anywhere that should know
that.
* Just to be annoying, this won't work at all on 32-bit OSX versions
unless we link everything with -headerpad_max_install_names. (I know
Apple forgot about 32-bit machines long ago, but our buildfarm hasn't.)
* Speaking of not working, I don't think this "find" invocation will
report any failure exits from install_name_tool.
* This doesn't fix anything for executables that never get installed,
for instance isolationtester.
We could probably fix the first four problems with some more sweat,
but I'm not seeing a plausible answer to the last one. Overwriting
isolationtester's rpath to make "make check" work would just break
it for "make installcheck".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-12-07 06:40:34 | Re: [Todo item] Add entry creation timestamp column to pg_stat_replication |
Previous Message | Ashutosh Bapat | 2018-12-07 05:43:45 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |