[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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...)



Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com

Reply to: