Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-08 Thread Michael Paquier
On Sun, Nov 8, 2015 at 7:26 AM, Tom Lane  wrote:
> "David E. Wheeler"  writes:
>> Apple says that the more people file bugs, the more likely the issue is to 
>> get attention. So by all means, please file radars 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


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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-07 Thread David E. Wheeler
On Nov 4, 2015, at 8:37 PM, Michael Paquier  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*Plus libraries. 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 radars about 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



smime.p7s
Description: S/MIME cryptographic signature


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-07 Thread Tom Lane
"David E. Wheeler"  writes:
> Apple says that the more people file bugs, the more likely the issue is to 
> get attention. So by all means, please file radars 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


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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-05 Thread Andres Freund
On 2015-11-05 12:51:48 +0900, Michael Paquier wrote:
> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut  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


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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-04 Thread Peter Eisentraut
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).



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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-04 Thread Michael Paquier
On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut  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


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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-04 Thread Tom Lane
Michael Paquier  writes:
> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut  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


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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-04 Thread Michael Paquier
On Thu, Nov 5, 2015 at 1:16 PM, Tom Lane  wrote:
> Michael Paquier  writes:
>> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut  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


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


Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

2015-11-03 Thread Andres Freund
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 
> #include 
> 
> 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