Thread
-
Re: [HACKERS] dynamic libraries
Oliver Elphick <olly@lfix.co.uk> — 1998-10-12T20:20:59Z
"Matthew N. Dodd" wrote: > 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. If you do this, Debian Linux will consider it a bug and I shall have to take it out for the Debian package. From Debian documentation: "`-rpath' can cause big problems if the referenced libraries get updated. Therefore, no Debian package should use the `-rpath' option." -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 ======================================== "Blessed is the man who makes the LORD his trust, who does not look to the proud, to those who turn aside to false gods." Psalms 40:4 -
Re: [HACKERS] dynamic libraries
Matthew N. Dodd <winter@jurai.net> — 1998-10-12T20:40:05Z
On Mon, 12 Oct 1998, Oliver Elphick wrote: > "Matthew N. Dodd" wrote: > > 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. > > If you do this, Debian Linux will consider it a bug and I shall have to take > it out for the Debian package. From Debian documentation: > > "`-rpath' can cause big problems if the referenced > libraries get updated. Therefore, no Debian package should use the > `-rpath' option." Yes, since Debian distributes binary packages where users can install the package anywhere they like, compiling in a search path causes problems. Let me ask you though, when was the last time you updated the shared libs and didn't update the utils that used them? Regardless, under ELF, a major number change will require relinking anyway as ELF has no 'major revision number'. A solution would be to compile in multiple probable locations for the library in to the binary. Another solution is to beat users up until they no longer have the desire to install packages in non-standard places. Regardless, just because Debian or any other system can't figure out how to do library versioning doesn't mean it should handycap any correct ELF library solution. The little warning you pased about -rpath is bogus; if the library changes and the minor version is bumped, no problems will be experienced because, by definition, such changes do not alter behavior. A change that would cause problems will require a relink anyway as you're no longer linking against the same library. (libpq1.so.0 vs libpq2.so.0). For those of you coming from an a.out or other background, your libraries aren't going to be named the same. I am not proposing any changes to the a.out library naming. ELF provides compiled in library search paths for a reason; it is the correct thing to do. How it effects binary packages of a particluar OS (FreeBSD, NetBSD, Debian or whatever) is beyond the scope of the postgresql development project. I'm pretty sure postgresql is provided in source form for that reason. :) BTW, you misspelled 'Debian GNU/Linux'. -- | 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? |
-
Re: [HACKERS] dynamic libraries
Jan Wieck <jwieck@debis.com> — 1998-10-13T07:50:07Z
Folks, this debate is becoming more and more a philosophic discussion about "if it is right to force end users to use -rpath or ld.so.conf". I think it's not the PostgreSQL developers teams subject to make a decision about it. And even if, I think we cannot make such a decision until release schedule of 6.4. PostgreSQL should be easily installable out of the box. On systems where ld.so.conf is the defacto standard, forcing -rpath will be IMHO a drawback against PostgreSQL (the user already made his OS decision). If using a search path means a loss of performance or security, systems where this is the standard way have other problems than those coming with PostgreSQL. We can clearify in the installation instructions that using ld.so.conf requires root permissions any time the library interface changes or LD_LIBRARY_PATH can be used (if a non privileged user wants to play around with it). For 6.5 we could discuss if using ld.so.conf, LD_LIBRARY_PATH or -rpath could become a configure option. What we never should do is to be arrogant and say "PostgreSQL MUST be installed using the ONE and ONLY correct way of shared library usage". This would only become a pseudo argument against PostgreSQL. Let's all calm down and release. There are end users waiting for the capabilities of 6.4. They don't care about how the shared libs are used as long as it's easy to use them. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] dynamic libraries
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-13T14:26:23Z
> Let's all calm down and release. There are end users waiting > for the capabilities of 6.4. They don't care about how the > shared libs are used as long as it's easy to use them. Don't panic Jan! I took up the discussion because Matthew seemed to have strong opinions on a subject that afaik is not an issue really. So I was hoping to learn more about the fine points, and I think I have. It looks like there may be pros and cons to each method, but for me the "old style" of using ld.conf.so allows some independence between apps and library location that -rpath/-R may not. I would expect that, as Jan suggests, it is best to leave the choice to the installer. Anyway, if Matthew wants to write up the way one would put an entry for LDFLAGS or LDFLAGS_SO or ?? in a Makefile.custom to get the behavior he is advocating I would be happy to include it in the Admin/installation docs as an installation tip or alternative. Matthew? - Tom -
Re: [HACKERS] dynamic libraries
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-13T15:24:33Z
> > Let's all calm down and release. There are end users waiting > > for the capabilities of 6.4. They don't care about how the > > shared libs are used as long as it's easy to use them. > > Don't panic Jan! I took up the discussion because Matthew seemed to have > strong opinions on a subject that afaik is not an issue really. So I was > hoping to learn more about the fine points, and I think I have. > > It looks like there may be pros and cons to each method, but for me the > "old style" of using ld.conf.so allows some independence between apps > and library location that -rpath/-R may not. > > I would expect that, as Jan suggests, it is best to leave the choice to > the installer. > > Anyway, if Matthew wants to write up the way one would put an entry for > LDFLAGS or LDFLAGS_SO or ?? in a Makefile.custom to get the behavior he > is advocating I would be happy to include it in the Admin/installation > docs as an installation tip or alternative. Frankly, I think the environment variable LD_RUN_PATH is the only way to go(see man ld.so). Setting the flag on every link, and for user apps too, seems too painful for regular use. -- 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
-
Re: [HACKERS] dynamic libraries
Matthew N. Dodd <winter@jurai.net> — 1998-10-13T16:05:32Z
On Tue, 13 Oct 1998, Thomas G. Lockhart wrote: > Anyway, if Matthew wants to write up the way one would put an entry for > LDFLAGS or LDFLAGS_SO or ?? in a Makefile.custom to get the behavior he > is advocating I would be happy to include it in the Admin/installation > docs as an installation tip or alternative. > > Matthew? When I install 6.4 on the systems here I'll see if I can make clean patches and submit them. Like I said in my first message this is a sore subject only because I run into it so much and few software packages seem to deal with it correctly. What PostgreSQL does won't really affect me as I'll just keep doing what I've been doing (along with lots of cursing). If my patches are of any use then maybe PostgreSQL won't be on my list of things to fix shared libs before compiling. Anyhow, getting 6.4 out is of paramount importance so this discussion is academic at this point. -- | 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? |
-
Re: [HACKERS] dynamic libraries
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-13T18:34:44Z
> Anyhow, getting 6.4 out is of paramount importance so this discussion > is academic at this point. Well, I was proposing that you document how to use the -rpath/-R style of building the v6.4beta. If you can do that in the next few days then it can appear in the v6.4 docs. If not, then it will wait for sometime later. In either case, we aren't proposing to change the current methods, which are independent of loader configuration and options (for example, those installing into /usr/lib just need to reboot to get ldconfig run), but rather allowing you to document the way you would suggest doing it. Your choice... - Tom -
Re: [HACKERS] dynamic libraries
Matthew N. Dodd <winter@jurai.net> — 1998-10-13T18:39:29Z
On Tue, 13 Oct 1998, Thomas G. Lockhart wrote: > Well, I was proposing that you document how to use the -rpath/-R style > of building the v6.4beta. If you can do that in the next few days then > it can appear in the v6.4 docs. If not, then it will wait for sometime > later. > > In either case, we aren't proposing to change the current methods, which > are independent of loader configuration and options (for example, those > installing into /usr/lib just need to reboot to get ldconfig run), but > rather allowing you to document the way you would suggest doing it. Well, for Solaris I've always added '-R' flags that correspond to the various -L flags in the appropriate make files. Since $(LIBDIR) is equal to $(POSTGRESDIR)/lib which is the final installation directory it kind of makes sense to use '-R' as we're only specifying additional linker search directories as supplied to us by the user. I suppose for Unixware we could 'setenv LD_RUN_PATH $(LIBDIR)' or something. -- | 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? |