Re: Question regarding dynamic_library_path

> The variations among platforms are great enough that I don't think you
> can make such an assertion.
>
> (To take one example, HPUX does have a variable like this --- they call
> it SHLIB_PATH --- but it *is not used* unless a flag enabling it was
> provided when the shlib was linked, and I think most people avoid doing
> that. Certainly we don't enable SHLIB_PATH in the shlibs we build in
> the standard Postgres distribution. Furthermore, AFAICT shl_load()
> requires an exact path spec for the initial shared library; it won't
> do a path search for that, only for dependencies.)
>
Here's an excerpt from the HPUX manual pages on dlopen(3C).

"First, any directories specified by the environment variable
LD_LIBRARY_PATH are searched. Next, any directories specified by SHLIB_PATH
are searched. Then, any directories specified by a DT_RPATH entry in the
.dynamic section of the original program object are searched. Finally, the
directories /usr/lib/hpux32 in 32-bit mode and /usr/lib/hpux64 in 64-bit
mode are searched."

> > The general idea is to let the OS find the shared library rather than
> have
> > the backend do it by itself. There's a flaw in the current design. IMHO,
> it
> > would be a good thing to improve it.
>
> I think we'd just be buying into a lot of pain and platform-specific
> behavior. Up to now we have not depended on knowing how to
> environmentally influence the dynamic linker, but with your proposal
> Postgres would be immediately broken anywhere that we didn't have that
> right. And there are places we *couldn't* get it right, see HPUX.
> I'm much more concerned about whether shared library loading works at
> all than about whether it's possible for one shlib to autoload another.
>
I don't agree. Propagating the dynamic_library_path to the loader will make
it work the way people would expect it to. Failing to do so is confusing
since the path you specified appears to be incorrect. The concept of shared
libs that are dependent on other shared libs is not uncommon. I think that
following the platform specific behavior is what PostgreSQL *should* do in
this case. And HPUX, as you can see, is no obstacle. I actually sincerely
doubt that you'll find a platform where shared libraries are enabled and
this cannot be done.

> If you want $libdir to be part of LD_LIBRARY_PATH on your platform, why
> don't you just set that up in the postmaster start script?

Yes, there's always a workaround for the problem and this is what I do
today. My suggestion is based on the assumption that it would be nice if the
dynamic_library_path actually worked for libraries loading libraries. The
discussion is pointless if that assumption is incorrect.

Kind regards,

Thomas Hallgren