On Jan 27, 1999, Ben Gertzfield <[EMAIL PROTECTED]> wrote: > This is bad for Debian, because in all binary packaging systems, > shared libraries can and will be moved around from time to time, as > policy and major upgrades (like libc5 -> libc6) mandate.
You might have included my suggestion to prevent having to move libraries in the first place: creating a libc6-specific directory right now, instead of installing libraries in /usr/lib and having to move them into another directory when libc7 should be released. > However, Alexandre Oliva <[EMAIL PROTECTED]> brings up an important > point: -rpath is necessary if one is installing libraries and binaries > linked to those libraries in one's home directory, or if your Unix has > no support for library search paths via environment variables like > Linux's LD_LIBRARY_PATH. More than that (and it was my fault to have failed to mention that before): libtool will hard-code the installation directory of the library into the `libdir' variable of the .la script it installs. Therefore, if one moves the library then tries to link with the .la file, he loses. There's also the dlopening issue: libltdl (to be released with libtool 1.3) will dlopen a library in the directory pointed to by `libdir' too. In general, I feel that moving libraries around is a very bad idea, because it will lead to failure most of the times, and that's why I don't feel libtool should help people doing that. > Basically, I have been asking Alexandre if it's possible to add a > --no-rpath option to libtool when calling it to tell it to not use > -rpath when linking binaries, but he refused, saying he'd have to port > that to 'hundreds of platforms'. Actually, not issuing -rpath or equivalent is quite easy to do, but choosing *when* not to do it is the part that is hard to port. Thomas Tanner has suggested that we could omit the -rpath switch for libraries that are supposed to be installed in directories listed in the default search path. However, the default search PATH might change, and, even if it did not, it would be possible to link an application with a library in, say, /usr/local/lib, and then find out that at run-time it loads a library with the same name in /usr/lib, because /usr/lib appears first in the standard search path. The other issue is *how* to specify that -rpath should be ommitted. Should it be a configure option, that would permanently disable any -rpath switches? Or should it be an additional argument to the libtool script at program-linking time? Or should it be specified at library linking time, with one of three options: hardcode path in the library, hardcode path in any program linked with it, or do not hardcode path at all? Or something else? What to do on a platform that doesn't support the requested hardcoding strategy? The issue is very complex because we can't think just of GNU/Linux with all its bells and whistles, because libtool is supposed to present an homogeneous, portable interface to creating libraries. -- 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