On Jan 27, 1999, "J.H.M. Dassen" <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote: >> 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. > I'm sorry, but this is IMHO completely backwards. On Linux systems, there is > nothing wrong with moving libraries around as the need arises. Except that you risk replacing a library with an incompatible one. That's what has caused you so much trouble. If, instead of moving the X11 libraries to another dir and creating new, incompatible versions under the same pathname, you had created new versions in other directories, no unexpected crashes would have occurred. > Having libtool default to -rpath is what's causing problems. This is IMHO completely backwards :-) When a program is linked with a shared library, a contract is established between them stating that the library (or any newer but compatible version thereof, on systems that support library versioning) will supply the symbols that the program resolved from it, and the program will be able to find the library at that point. If you move the library and replace it with an incompatible one, you're breaking the contract and the versioning mechanism, so you can't blame the program for crashing, nor the tool that created the program. > I've seen one too many instances of "<foo> crashes on Debian" that turned > out to be "<foo> is a libc5 binary with an RPATH of /usr/X11R6/lib" which on > any reasonably up to date Debian system contains libc6 X libraries. See? You replaced one library with an incompatible one without modifying its version number to mark it as incompatible. Isn't this breaking the contract? How could you expect it to work? > The X example also shows that the problem isn't limited to /usr/lib either. > What's next? /usr/local/lib/libc6 ? Maybe some library versioning mechanism that allows incompatible changes to be marked as such. Maybe an environment variable or some file in /etc containing a number that will be added to the major version number of any library libtool creates, so that they will be marked as incompatible. >> > 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, > That is a special case. The default should be sane for regular cases. You see the regular case as the one you use the most. I see it as the one I use the most. I don't install any packages in /usr or /usr/local because I find it *horrible* to have a huge /usr/local/bin without any clear separation between packages. It's a pity that the GNU/Linux distributions don't care about clearly separating packages from one another... >> > or if your Unix has no support for library search paths via environment >> > variables like Linux's LD_LIBRARY_PATH. > While I appreciate concerns about supporting less fortunate operating > environments, I don't think their existence should hold us back from doing > the right thing on Linux. For which definition of the right thing? :-) >> 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. > I see no reason why moving libraries around is a bad idea. I see defaulting > to -rpath as a bad idea, which breaks moving libraries around. Because you break a contract every time you remove a library from the place in which it used to live. -- 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