From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | 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 13:38:42 |
Message-ID: | 15250.1273153122@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Greg Stark wrote
>> We only set RPATH if the install location isn't part of the default ld
>> library path specified by /etc/ld.so.conf right? Setting it if it is
>> in the default path would be antisocial.
> How are we going to know at build time what is in the ld.soconf of the
> installation machine?
Exactly. In practice, it's on the packager's head to specify
--disable-rpath if he intends to install into the platform's
regular library search path.
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
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2010-05-06 13:51:41 | pg_stat_transaction patch |
Previous Message | Bruce Momjian | 2010-05-06 13:06:26 | Re: pg_migrator to /contrib in a later 9.0 beta |