LD_LIBRARY_PATH versus rpath

Поиск
Список
Период
Сортировка
От Tom Lane
Тема LD_LIBRARY_PATH versus rpath
Дата
Msg-id 514.1273101643@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: LD_LIBRARY_PATH versus rpath  (Greg Stark <gsstark@mit.edu>)
Re: LD_LIBRARY_PATH versus rpath  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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.

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 DT_RPATH entry pointing at the
intended final installation lib/.  And DT_RPATH overrides
LD_LIBRARY_PATH, in the Linux dynamic loader.  man ld.so says:
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
ifpresent 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-IDbinary, in which case it is         ignored.
 
      o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic         section attribute of the binary
ifpresent.
 
      o  (etc etc)

Given that deprecation note, and the fact that what we're doing entirely
fails to work as desired, it seems like what we need to do is set
DT_RUNPATH instead of DT_RPATH.  Further reading discloses that the
way to do that is to add "--enable-new-dtags" to the linker switches.

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 asked around at Red Hat and was told that this would be unlikely
to have any negative side-effects, but I'm not sure how thoroughly
those guys thought about the consequences for non-mainstream Linux
machines.  (In particular, I'm worried about really old distros
possibly not having this switch.)

My inclination is to try this in HEAD only and see if any problems
emerge during the beta cycle.

Comments?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: max_standby_delay considered harmful
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: Reg: SQL Query for Postgres 8.4.3