On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote: >> Since you do support -rpath in your system, you should probably extend >> your dynamic linker to work in this case too, or risk taking the blame >> for silently breaking applications, if the poor user ever understands >> what happened to his program.
> Note that 'we' (Debian) write neither the kernel, nor the dynamic linker. Sorry, I had assumed you had hacked the dynamic linker in order to support the /libc5 compatibility libraries. > You have previously objected to a proposed solution on the grounds that > 'you want libtool to work on all systems'. It seems to me that if you > want to make libtool work on Linux, you should find a way of disabling > rpath, since rpath is broken on Linux. rpath is not broken, it just won't let one replace a library (meaning moving a library to another directory and installing a new library in its place) with one that appears to be compatible, according to the version numbers, but is not. That's the root of the problem, and that's why you want so much libtool not to use -rpath. I feel we're not going to make progress in this discussion unless someone comes up with a bright idea about how to allow the user to select when/how to hardcode rpaths or not. In the beginning of this discussion, Thomas Tanner suggested that -rpath could be dropped if it would specify a standard library search directory. Although I see problems in this behavior, that I have exposed in other messages, I think it is a reasonable trade-off, and I'm willing to accept a patch for libtool that would add to AC_PROG_LIBTOOL some code that would check whether enable_libtool_hardcoding_of_default_search_dirs=no (but --disable-libtool-... should remain undocumented by now) and, in this case, pass some flag to ltconfig that causes it to create a libtool script that drops rpaths (but not xrpaths) that specify directories listed in sys_lib_search_path_spec. However, I'd like to ask you to avoid distributing packages with pre-``compiled'' libtool scripts with such hardcoding disabled, particularly the libtool Debian package. This arrangement should take care of your immediate needs, while we try to find a better way to do it, or even decide to do it by default. > However, our dynamic linker *does* understand the problem. And it *does* > have a solution to it. And -rpath turns it off. So we cannot afford to > use -rpath. As I have already pointed out, the solution is not complete, otherwise you'd not be observing any problem. -- 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
