RE: What hack in ld.so?
> -----Original Message-----
> From: Alexandre Oliva [mailto:oliva@dcc.unicamp.br]
> Sent: Saturday, January 30, 1999 11:39 PM
> To: Buddha Buck
> Cc: Jason Gunthorpe; Debian Developers; bug-libtool@gnu.org
> Subject: Re: What hack in ld.so?
>
>
> On Jan 29, 1999, Buddha Buck <bmbuck@acsu.buffalo.edu> 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: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------
Reply to: