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 off-list investigation and
> found that this appears to be a generic issue on Linux. pg_regress
> invokes psql, which depends on libpq.so, and if psql fails due to
> picking up the wrong libpq.so then you get behavior as described.
Yeah, that's been broken since forever.
> The shared libraries needed by the program are searched for in the fol-
> lowing order:
>
> o (ELF only) Using the directories specified in the DT_RPATH dynamic
> section attribute of the binary if present and DT_RUNPATH attribute
> does not exist. Use of DT_RPATH is deprecated.
>
> o Using the environment variable LD_LIBRARY_PATH. Except if the exe-
> cutable is a set-user-ID/set-group-ID binary, in which case it is
> ignored.
>
> o (ELF only) Using the directories specified in the DT_RUNPATH dynamic
> section attribute of the binary if present.
Ah, that sounds good.
> So the question is, should we modify Makefile.linux along the lines of
>
> -rpath = -Wl,-rpath,'$(rpathdir)'
> +rpath = -Wl,-rpath,'$(rpathdir)',--enable-new-dtags
I see this feature was added in 2001, so it should be OK to use.
> My inclination is to try this in HEAD only and see if any problems
> emerge during the beta cycle.
I wouldn't consider backpatching it at all.
