[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -rpath with libtool and Debian Linux

On Jan 27, 1999, Jules Bean <jmlb2@hermes.cam.ac.uk> 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  aoliva@{acm.org}
Universidade Estadual de Campinas, SP, Brasil

Reply to: