> -----Original Message----- > From: Alexandre Oliva [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 30, 1999 11:39 PM > To: Buddha Buck > Cc: Jason Gunthorpe; Debian Developers; [EMAIL PROTECTED] > Subject: Re: What hack in ld.so? > > > On Jan 29, 1999, Buddha Buck <[EMAIL PROTECTED]> wrote: > > [exact description of what I had assumed about the behavior of > ld.so, based on previous postings to the libtool mailing list, > snipped] > > > This is not how I understand how the ld.so linker works on Linux > > systems. My understanding is that it caches the locations > of all known > > versions of the libraries, and makes an intelligent decision as to > > which version to load. > > [description of what I now understand to b e the current behavior of > ld.so snipped] > > > This breaks in the presense of -rpath, because with rpath, > bar is not > > dependent on libfoo, but on /usr/lib/libfoo. > > It shouldn't break, because -rpath is not associated with particular > libraries, it is just a search path, just like the default search > path. In order for ld.so to do an intelligent decision about whihc > version to load, it should probably take into account the hard-coded > rpath in addition to the default search path, preferring hard-coded > rpaths as long as they do not introduce conflicts. > > Obviously, this would have never been needed if old libraries had not > been replaced with (in)compatible versions, but the maintainers of > Debian have already taken this step, despite the fact that this would > break any previously-compiled programs that happened to hard-code > /usr/lib or /usr/X11R6/lib. Therefore, new code must be written to > support this step.
I agree with you up to now, but > > Since modifying the next release of libtool won't contribute at all to > fix the problem in already compiled programs, which are the only > programs affected by this problem, I don't see much point in > introducing a quick hack in libtool to prevent hard-coding of paths in > libtool at this point. If/when someone contributes a portable and > user/developer-configurable mechanism to do that, we may adopt it. THIS part of your statement is wrong, at least in my case :-( I usually still build production code with a libc5 setup, and will continue to do so for a while: I cannot force all my users to switch to libc6 (even if it's free, it cost quite a lot to migrate a production system with several people hooked on). I *have* to build programs that work on various, libc5 or libc6 based, linux boxes, so I build *new* programs with a libc5 setup, and I woudl like to be able to use libtool instead of having to had-craft shared library setup (remember I also have to work on Suns, HPs, etc...) Regards, Bernard -------------------------------------------- Bernard Dautrevaux Microprocess Ingéniérie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel: +33 (0) 1 47 68 80 80 Fax: +33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------