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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
