On Friday 20 July 2001 19:56, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > How is this search path defined? Blindly using libdir is not ok --
> Why not?
During RPM build, libdir will point to /usr/lib. This is OK and appropriate
for the generally-loadable shared libs. HOWEVER, the shared objects that are
affected by this function handler load search path will not be located in
/usr/lib -- as they are not generally loadable shared libraries, but
PostgreSQL-only shared libraries. Thus, /usr/lib/pgsql is the home for
those, and, in an RPM installation, should be the head of any shared object
load path searched by the PostgreSQL dynaloader.
/usr/lib -> system dynaloader default for non-essentials (/lib of course for
libs essential for boot)
/usr/lib/pgsql -> PostgreSQL dynaloader default (ideally, on an FHS-compliant
installation).
> The search path is defined in postgresql.conf (and I see Peter forgot
> to add an example to the postgresql.conf.sample file), but the default
> is the backend-compile-time $libdir. Offhand I don't see what's wrong
> with it.
I can patch postgresql.conf.sample easily enough -- but, if I'm trying to get
away from RPM-specific patches.... :-) I have heretofore not modified the
default postgresql.conf in anyway -- no tuning, no tcpip_socket setting (for
which I get some grief, as people running RPMs of 7.0.x are used to -i being
on by default), no nothing.
Not knowing alot about autoconf, I hesitate to suggest or ask the following,
but I will anyway -- is it possible to define an optional
'so-search-path-default' switch for the backend's dynaloader? This has
nothing to do with the OS dynaloader path, for which there is a well-defined
config file on most OS's -- just the backend's function handler dynaloader.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11