Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jules Bean <jmlb2@hermes.cam.ac.uk> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
>> > 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 [...] 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.
> The contract does not state that the library will be found in a particular
> location on the filesystem hierarchy.
Correct.
> The contract simply states that the library will be found. Which
> library is used can be determined by the linker.
Except that, if you replace the library with an incompatible one, you
*are* breaking the contract.
Furthermore, there's no reason to assume that the user will *not* have
used -rpath himself, so moving libraries does have a potential for
breaking user programs, therefore it should best be avoided.
> Where is the need for rpath here?
There's no need for it, but it doesn't cause any harm unless you break
the rules, i.e., replace a library with an incompatible one that holds
an apparently compatible version number. *This* is the root of all
your problems, not that fact that a rpath is specified. If you had
not replaced libraries with incompatible versions, the dynamic linker
would not have found it in the hard-coded rpath and would look for it
in the default search path, and find it in the appropriate alternate
location.
>> 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?
> It did work. On all binaries without -rpath. It worked. What do you
> mean, 'How could we expect it to work?'
Except for this `minor' restriction. You may be silently breaking
*user* programs because they have chosed to specify -rpath where it
was not necessary. If you think people *must not* use -rpath on your
system, you'd better completely disable it, not blame the user for
making use of a (IMO nice) feature of your system.
I think a solution that is not general is not a good solution. Since
the solution of moving shared libraries around has the potential of
causing problems, if I were you, I'd work harder to try to find a
complete solution (which I happen to have already suggested) instead
of trying to blame libtool or other users for doing things that are
perfectly correct, but not in the way that would let you replace
incompatible libraries.
> Our distribution cares greatly about separating packages from each other.
Not from the point of view of the end user. When they want to find a
tool, they may `ls /usr/bin /usr/local/bin' and will be presented
*thousands* of files. I'd rather have a classification system in
which I could have links (or similar) to all programs in a common
directory, but in which I could search for programs by subject. I'd
like to have development tools such as compilers in one directory,
text writing tools such as word processors and text editors in
another, system administration utilities in another, and so on.
Additionally, I'd like to be able to keep multiple versions of a
package installed, and the only way I could do that is by installing
each version in a separate directory, and selecting which version to
use via soft-links in the directory that happens to be in my PATH.
How does the current packaging system allows me to test one version of
a package while other users of the same host are running a stable
version of that tool? Or are the GNU/Linux distributions all moving
towards the Micro$oft model of single-user workstations?
--
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: