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.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. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers