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. 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 [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
