Re: LD_LIBRARY_PATH versus rpath

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

In response to

Responses

Browse pgsql-hackers by date

  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