Thread

1. Re: [HACKERS] dynamic libraries

   Billy G. Allie <bill.allie@mug.org> — 1998-10-13T06:03:09Z

   > 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:
   
   I am running UnixWare 7.01, a System V Release 4 based system.  It is an ELF based system with roots back to the first ELF based systems.  It's linker does not have a -R or --rpath option.  To have UnixWare's ld command embed the location of the shared libraries into the executable, you set the LD_RUN_PATH to the path(s) containing the libraries.  From the syntax of the --rpath option, it is apparent you are running the GNU C compiler with ELF support (an upstart, late commer in the world of ELF support).  You should know that the one true path of ELF support is to use the LD_RUN_PATH environment variable, not -R/--rpath :->  I find it much easier to set LD_RUN_PATH then to have configure figure out that the a system is running GNU C with ELF support and for that system only, use -R/--rpath.  Check out your ld command.  If it supports LD_LIBRARY_PATH, it probably supprorts LD_RUN_PATH.  If it does, then use it to embed the library locations into your executable.
   -- 
   ____       | 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-13T15:15:43Z

   On Tue, 13 Oct 1998, Billy G. Allie wrote:
   > I am running UnixWare 7.01, a System V Release 4 based system.  It is
   > an ELF based system with roots back to the first ELF based systems.  
   > It's linker does not have a -R or --rpath option.  To have UnixWare's
   > ld command embed the location of the shared libraries into the
   > executable, you set the LD_RUN_PATH to the path(s) containing the
   > libraries.
   
   Ok.
   
   > From the syntax of the --rpath option, it is apparent you are running
   > the GNU C compiler with ELF support (an upstart, late commer in the
   > world of ELF support).  
   
   Actually, while I did mention --rpath (In the context of a FreeBSD/ELF or
   Linux/ELF system) I am running Solaris which uses the -R flag to tell
   ld(1) where things are.  -R takes prescedence over LD_RUN_PATH according
   to my doc.
   
   > You should know that the one true path of ELF support is to use the
   > LD_RUN_PATH environment variable, not -R/--rpath :-> I find it much
   > easier to set LD_RUN_PATH then to have configure figure out that the a
   > system is running GNU C with ELF support and for that system only, use
   > -R/--rpath.  Check out your ld command.  If it supports
   > LD_LIBRARY_PATH, it probably supprorts LD_RUN_PATH.  If it does, then
   > use it to embed the library locations into your executable.
   
   I'm pretty sure all ELF systems support LD_LIBRARY_PATH and LD_RUN_PATH.
   Using -R/--rpath allows us to have better control of what search paths are
   compiled in.  Who knows what the user has LD_RUN_PATH set to.  Should
   configure ask them if they want to use LD_RUN_PATH as well?  Should we
   find all the libraries we are to link with and construct our own
   -R/--rpath?  For systems that don't support -R/--rpath we'll have to do
   this anyway as we'll be messing with LD_RUN_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?   |