Re: [HACKERS] dynamic libraries - Mailing list pgsql-hackers
From | Matthew N. Dodd |
---|---|
Subject | Re: [HACKERS] dynamic libraries |
Date | |
Msg-id | Pine.BSF.4.02.9810121123080.16487-100000@sasami.jurai.net Whole thread Raw |
In response to | Re: [HACKERS] dynamic libraries ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Responses |
Re: [HACKERS] dynamic libraries
|
List | pgsql-hackers |
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? |
pgsql-hackers by date: