Re: Shared library search paths - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Shared library search paths
Date
Msg-id Pine.LNX.4.21.0007192132450.24612-100000@localhost.localdomain
Whole thread Raw
In response to Re: Shared library search paths  ("Oliver Elphick" <olly@lfix.co.uk>)
Responses Re: Shared library search paths
List pgsql-hackers
Oliver Elphick writes:

> As far as Debian is concerned, use of rpath is a bug.  Here's a quote from
> some Debian system documentation:
>
>   libtool automatically inserts `-rpath' settings when compiling your
>   program.

I don't think so.

> But `-rpath' can cause big problems if the referenced
>   libraries get updated. Therefore, no Debian package should use the
>   `-rpath' option.

I'm not sure I buy that. All -rpath does is add a directory to the search
path that the program consults at runtime for its shared libraries. So
it's just an alternative in place of

hard-coded into dynamic linker
/etc/ld.so.conf
LD_LIBRARY_PATH

but it's the terminally accurate alternative.

What does happen if the referenced library gets updated? Nothing. -rpath
doesn't reference any libraries, it just suggests to the runtime linker
where it might look for one. I don't want to use it to find system
libraries, I just want psql to find libpq, and the right libpq, and I want
to relieve installers from having to fiddle around with these settings.

>   libtool also refuses to link shared libraries against other shared
>   libraries.

I don't think so.


--
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: About these IPC parameters
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: btree split logic is fragile in the presence of lar ge index items