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.
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.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: