Thread: OS X El Capitan and DYLD_LIBRARY_PATH
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.
Consequently, the current in-tree "make check" test setup will no longer
work, because programs such as initdb and psql that are called several
layers down will no longer be pointed to the right libraries. If you
run "make install" before "make check", it will work; otherwise
something will either fail because it can't find the libraries, or it
might pick up libraries found somewhere else, with poor outcomes, in my
experience.
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.
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
On 11/3/15 6:36 AM, Andres Freund wrote: > 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. That might be worth a try. I ended up disabling system integrity protection, which also fixed a few other strange behaviors (mysterious regression test failures in ecpg, for instance, if anyone stumbles across that).
On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On 11/3/15 6:36 AM, Andres Freund wrote: >> 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. > > That might be worth a try. I ended up disabling system integrity > protection, which also fixed a few other strange behaviors (mysterious > regression test failures in ecpg, for instance, if anyone stumbles > across that). Yeah, that's wiser IMO. I would expect at the end people doing some serious development work to disable SIP at the end, this is known as well to cause issues with homebrew for example. -- Michael
Michael Paquier <michael.paquier@gmail.com> writes:
> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> That might be worth a try. I ended up disabling system integrity
>> protection, which also fixed a few other strange behaviors (mysterious
>> regression test failures in ecpg, for instance, if anyone stumbles
>> across that).
> Yeah, that's wiser IMO. I would expect at the end people doing some
> serious development work to disable SIP at the end, this is known as
> well to cause issues with homebrew for example.
I think we should all file bugs telling Apple it's insane to suppress
DYLD_LIBRARY_PATH across a shell invocation. I can see the point of
it for some other system binaries, but not sh.
regards, tom lane
On Thu, Nov 5, 2015 at 1:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >>> That might be worth a try. I ended up disabling system integrity >>> protection, which also fixed a few other strange behaviors (mysterious >>> regression test failures in ecpg, for instance, if anyone stumbles >>> across that). > >> Yeah, that's wiser IMO. I would expect at the end people doing some >> serious development work to disable SIP at the end, this is known as >> well to cause issues with homebrew for example. > > I think we should all file bugs telling Apple it's insane to suppress > DYLD_LIBRARY_PATH across a shell invocation. I can see the point of > it for some other system binaries, but not sh. There is: http://openradar.appspot.com/22807197 And it seems that this is intended policy because python, perl, bash, etc processes are running as protected processes even if there script is not, and all the dldy variables are getting purged: https://forums.developer.apple.com/thread/13161 -- Michael
On 2015-11-05 12:51:48 +0900, Michael Paquier wrote: > On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > > On 11/3/15 6:36 AM, Andres Freund wrote: > >> 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. > > > > That might be worth a try. It'll probably not me though, given that I scream bloody murder everytime I've to use OSX... > > I ended up disabling system integrity > > protection, which also fixed a few other strange behaviors (mysterious > > regression test failures in ecpg, for instance, if anyone stumbles > > across that). > > Yeah, that's wiser IMO. That's probably true in the short term. I doubt it'll be viable in the long run. Both because apple obviously doesn't care one iota about the developer experience around this, and thus probably has a limited interest keeping related procedures working the same, and because once more people use El Captan it'll have to be done by more and more people. Andres
On Nov 4, 2015, at 8:37 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > There is: > http://openradar.appspot.com/22807197 Yep, I filed that because I was unable to build the DBD::Oracle Perl module, since I can’t tell it where to find the SQL*Pluslibraries. Big PITA. Apple says that the more people file bugs, the more likely the issue is to get attention. So by all means, please file radarsabout this. You can reference 21732670 as the bug you’re duping (they marked mine as a dupe for that one). https://http://bugreport.apple.com/ Best, David
"David E. Wheeler" <david@justatheory.com> writes:
> Apple says that the more people file bugs, the more likely the issue is to get attention. So by all means, please
fileradars about this. You can reference 21732670 as the bug you’re duping (they marked mine as a dupe for that one).
Done here.
regards, tom lane
On Sun, Nov 8, 2015 at 7:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "David E. Wheeler" <david@justatheory.com> writes: >> Apple says that the more people file bugs, the more likely the issue is to get attention. So by all means, please fileradars about this. You can reference 21732670 as the bug you’re duping (they marked mine as a dupe for that one). > > Done here. Let's be noisy. -- Michael