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 a
"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.
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, t
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.
> >>
> >> Alternativel
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 te
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
>
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
>> a
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_l
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 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
10 matches
Mail list logo
