Horton

Thread

  1. Re: [HACKERS] dynamic libraries

    Billy G. Allie <bill.allie@mug.org> — 1998-10-10T02:24:16Z

    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.
-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    |

  2. Re: [HACKERS] dynamic libraries

    Matthew N. Dodd <winter@jurai.net> — 1998-10-12T05:57:37Z

    On Fri, 9 Oct 1998, Billy G. Allie wrote:
> 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.

Damnit, I'm really getting annoyed by all of this...  An ELF system should
not be using ldconfig or LD_LIBRARY_PATH to find its libraries.

ELF executables are told where to find their binaries at compile time.  On
Solaris this involves using '-R/path/to/libs' to add the 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.)

If PostgreSQL is not doing this IT IS BROKEN.

Regardless, do whatever you want; I keep on fixing this myself when I
compile new releases so I'm not likely to notice any further brokeness.

Have a good one.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |

  3. Re: [HACKERS] dynamic libraries

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-12T14:58:28Z

    > > 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
restrictive.

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...

                      - Tom

  4. Re: [HACKERS] dynamic libraries

    Matthew N. Dodd <winter@jurai.net> — 1998-10-12T15:36:07Z

    On Mon, 12 Oct 1998, Thomas G. Lockhart wrote:
> 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
> restrictive.

I'm not sure how that is a feature at all.  Having loads of junk in your
library search path really slows things down.

An ELF system does not have an ld.so.conf.  (Note that FreeBSD/ELF does
have an ld.so.conf but I believe this is only for transition purposes.)

If you (the system administrator) install a package, you know where it is
installed.  You are able let the binary take care of tracking where its
libraries are supposed to be, not the system.

> 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.

Having to set LD_LIBRARY_PATH to make things work is bogus; what if
someone forgets to set it?  What if a user can't edit ld.so.conf (ignoring
the fact that it won't exist on a real ELF system).

Compiling the information into the binary is much prefered.  If for some
reason you have to move the libraries, using LD_LIBRARY_PATH to keep them
running is a good bandaid until you can recimpile or edit the compiled in
paths (if your system supports such tools.)

> 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...

Elf systems have no 'major' version number.  On an a.out system you'd get
something like 'libpq.so.1.1'.  ELF would call this library 'libpq1.so'
which would be a link to 'libpq1.so.1'.  If the 'major' number is to be
changed (ie: an incompatible interface change was made) you must change
the name of the library.  For a.out it would become 'libpq.so.2.0' and ELF
'libpq2.so -> libpq2.so.0'.

Anyhow, in summary, depending on enviornment variables or a hacked linkrer
that supports 'ld.so.conf' is a bad thing on a real ELF system.  ELF
provides for compiled in search paths and they should be used.  This
reduces the additional steps a user must take to have a running system and
does not violate the POLA.  Since the compile/build process knows where
the install destination will be, nothing prevents it from doing the right
thing and using '-R' or '-rpath' ld(1) directives to set the search path.

I've done the whole LD_LIBRARY_PATH and it sucks; I had one that was
nearly a page long.  How the heck do you maintain such a thing and make
sure nobody else introduces a trojaned library that appears earlier in
your path?

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |

  5. Re: [HACKERS] dynamic libraries

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-12T16:01:50Z

    > Anyhow, in summary, depending on enviornment variables or a hacked linkrer
> that supports 'ld.so.conf' is a bad thing on a real ELF system.  ELF
> provides for compiled in search paths and they should be used.  This
> reduces the additional steps a user must take to have a running system and
> does not violate the POLA.  Since the compile/build process knows where
> the install destination will be, nothing prevents it from doing the right
> thing and using '-R' or '-rpath' ld(1) directives to set the search path.

Just to comment.  If we use -R or -rpath, people need to use that for
_every_ application that uses libpq, etc.  That seems like a pain to me.

B1ecause people have not had problems in the past using ld.so.conf, and I
can see them having problems with -R or -rpath, I would hesistate to
change it, though I can see why some installations would prefer the
-R/-rpath.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  6. Re: [HACKERS] dynamic libraries

    Matthew N. Dodd <winter@jurai.net> — 1998-10-12T16:18:13Z

    On Mon, 12 Oct 1998, Bruce Momjian wrote:
> Just to comment.  If we use -R or -rpath, people need to use that for
> _every_ application that uses libpq, etc.  That seems like a pain to me.

The alternative is more painful.  If PostgreSQL were the only application
package installed on a system your LD_LIBRARY_PATH would be really short.

> B1ecause people have not had problems in the past using ld.so.conf, and I
> can see them having problems with -R or -rpath, I would hesistate to
> change it, though I can see why some installations would prefer the
> -R/-rpath.

I'll continue to ignore the fact that some ELF systems do have a
bastardized runtime linker and use ld.so.conf when I state that ELF
systems have no ld.so.conf, so its LD_LIBRARY_PATH or -R/--rpath (I looked
up the flag finally.)

ld.so.conf or ldconfig with various directories on the command line is
necessary for a non-ELF system; this is the way you do things.  ELF fixes
this (the problem is when you have a zillion different directories to
search for libraries in and it starts taking a long time to start
dynamically linked programs on a loaded system.  I'll assume everyoen sees
the security problems with a system wide library path.)  So for a.out or
other non-ELF systems, I'm proposing no change; do whatever works.  For
ELF, the specification supports compiled in library search paths; lets use
them.  Asking the system administrator to keep track of another library
path is most assuming.  -R/--rpath also makes it simpler for non-root
users to install PostgreSQL.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |