> > On UnixWare 7.0 (and Solaris systems, also) I export LD_RUN_PATH
> > which contains the paths to the dynamic libraries. When the linker
> > runs, it incorporates the paths into the output file so that
> > LD_LIBRARY_PATH is not needed to find the needed dynamic libraries.
<gratuitous griping snipped :)>
> ...An ELF system should
> not be using ldconfig or LD_LIBRARY_PATH to find its libraries.
It sounds like you have a strong opinion on this, but I'll need more
info to help convince/educate me...
> ELF executables are told where to find their binaries at compile time.
> On Solaris this involves using '-R/path/to/libs' to add a path to
> be compiled into the binary. I believe this works for Linux/ELF as
> well. FreeBSD/ELF is using -rpath I think, but someone should check.
> (I'm converting my 3.0-current system to ELF at the moment but its
> only a 486dx50 so its kind of slow.)
A nice feature of putting libraries into /etc/ld.so.conf is that the
libraries are found automatically as a system resource. Hard-linking the
paths (or possible paths) in the executable seems to be a bit
Since ld.so.conf is a very useful feature for linking with at least some
kinds of libraries, perhaps you can suggest or point to the guidelines a
system builder would use to choose what mechanism to use for a specific
case? I could image guidelines that would say to put system-wide
resources into ld.so.conf, and user-installed resources into
LD_LIBRARY_PATH or the "-R/r" flags.
The recent bump in libpq version number (entirely appropriate imho)
illustrated the downside to using ld.so.conf in that my root account had
to rerun ldconfig to make the new library known to the system. otoh it
was really easy to do...
In response to
pgsql-hackers by date
|Next:||From: Thomas G. Lockhart||Date: 1998-10-12 15:03:55|
|Subject: Re: [HACKERS] Parser breakage: "timestamp" has become a reserved word|
|Previous:||From: Bruce Momjian||Date: 1998-10-12 14:44:17|
|Subject: Re: [HACKERS] postmaster locking issues.|