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:
> ```
> ```
> 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:
 % install_name_tool -change libbz2.1.0.2.dylib  
@executable_path/../Frameworks/libbz2.1.0.2.dylib MyFunBinary

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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to