| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Andy Colson <andy(at)squeakycode(dot)net> |
| Subject: | Re: LD_LIBRARY_PATH versus rpath |
| Date: | 2010-05-06 14:37:59 |
| Message-ID: | 1273156679.17372.10.camel@fsopti579.F-Secure.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 in the ldconfig path; it's in
> some version-numbered directory and they don't provide any link or
> ldconfig entry so you could find it otherwise. Annoying as heck.
> I've always wondered how many other packagers have to carry patches
> similar to
> http://cvs.fedoraproject.org/viewvc/rpms/postgresql/devel/postgresql-perl-rpath.patch
Debian has libperl in /usr/lib, so there is no issue. But if there
were, there is a relatively new policy that you can should use rpath if
you need a library that is installed in a nonstandard path. (Should
actually use this new runpath thing, perhaps.) The same new policy
prohibits packages from modifying /etc/ld.so.conf.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-05-06 14:38:12 | Re: Partitioning/inherited tables vs FKs |
| Previous Message | Tom Lane | 2010-05-06 14:27:09 | Re: possible memory leak with SRFs |