Hi,
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>
>
> int
> main()
> {
> 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
> moment.
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:
http://qin.laya.com/tech_coding_help/dylib_linking.html% install_name_tool -change libbz2.1.0.2.dylib
@executable_path/../Frameworks/libbz2.1.0.2.dylibMyFunBinary
which ought to work independently from the tempinstall and normal
installation path.
Since I'm not a mac user I won't be able to check this out myself.
Andres
