On 2015-10-14 11:24:27 -0400, Peter Eisentraut wrote:
> The new OS X release 10.11 "El Capitan" has a "security" feature that
> prevents passing DYLD_LIBRARY_PATH to child processes. Somehow, that
> variable is stripped from the environment.
Two colleagues of mine at Citus just hit that.
> The exact specifications of this new behavior aren't clear to me yet.
> For example, this C program works just fine:
> #include <stdio.h>
> #include <stdlib.h>
> printf("DYLD_LIBRARY_PATH = %s\n", getenv("DYLD_LIBRARY_PATH"));
> return 0;
> but this shell script does not:
> echo "DYLD_LIBRARY_PATH = $DYLD_LIBRARY_PATH"
> There is breakage all over the Internet if you search for this, but the
> full details don't appear to be very clear.
> One workaround is to disable System Integrity Protection, effectively
> restoring the behavior of the previous OS release.
> Or don't upgrade quite yet if you don't want to deal with this at the
Apparently the behaviour is that DYLD_LIBRARY_PATH is prevented from
being inherited into any system binaries. E.g. a shell. But specifying
it inside a shell script will allow it to be inherited to children of
that shell, unless the child is a protected process in turn.
I wonder if we could fix this by using install_name_tool during the
tempinstall to add an appropriate rpath.
Alternatively we could, apparently, specify a relative path to libraries
as explained here:
% install_name_tool -change libbz22.214.171.124.dylib
which ought to work independently from the tempinstall and normal
Since I'm not a mac user I won't be able to check this out myself.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: