On Thu, May 6, 2010 at 12:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Now, pg_regress tries to ensure that the temporary installation
will work as desired by setting LD_LIBRARY_PATH to point at the
temp installation's lib/ directory. However, the psql executable
will by default get built with a
On ons, 2010-05-05 at 19:20 -0400, Tom Lane wrote:
Over at
http://archives.postgresql.org/pgsql-general/2010-05/msg00091.php
we have a complaint about make check failing when the install is
intended to overwrite existing libraries (in particular, replacing
8.4 with 9.0 libpq). I've done some
On tor, 2010-05-06 at 11:20 +0100, Greg Stark wrote:
We only set RPATH if the install location isn't part of the default ld
library path specified by /etc/ld.so.conf right?
No. How would you determine that?
Setting it if it is
in the default path would be antisocial.
That's why there is
Greg Stark wrote
We only set RPATH if the install location isn't part of the default ld
library path specified by /etc/ld.so.conf right? Setting it if it is
in the default path would be antisocial.
How are we going to know at build time what is in the ld.soconf of the
installation
Andrew Dunstan and...@dunslane.net writes:
Greg Stark wrote
We only set RPATH if the install location isn't part of the default ld
library path specified by /etc/ld.so.conf right? Setting it if it is
in the default path would be antisocial.
How are we going to know at build time what is in
On tor, 2010-05-06 at 09:38 -0400, Tom Lane wrote:
Funny point here: in the Fedora/RHEL RPMs, I use --disable-rpath
because don't use RPATH is part of the standard packaging guidelines
for that platform. However, pl/perl has to double back and use rpath
anyway because libperl.so doesn't exist
Over at
http://archives.postgresql.org/pgsql-general/2010-05/msg00091.php
we have a complaint about make check failing when the install is
intended to overwrite existing libraries (in particular, replacing
8.4 with 9.0 libpq). I've done some off-list investigation and
found that this appears to
