Re: LD_LIBRARY_PATH versus rpath

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.