[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:

> On 27 Jan 1999, Alexandre Oliva wrote:

> Can you tell -rpath to store the rpath for libmycustomthing.so and
> not for libc.so?

No, but, on some systems (for example, GNU/Linux), it is possible to
hard-code the full pathname of libmycustomthing.so into the shared
library itself, so that -rpath isn't needed, and the library cannot
ever be moved.

>> And that's the very reason why I've never been able to adopt any of
>> the available packaging systems: the only way to keep multiple
>> working versions is to use a separate directory for each version of
>> each package.

> In general, it is not useful to have multiple versions of the same
> package.

You're probably talking about the single-user workstation model.  I'm
talking about a networked multi-user model, in which some users need
(for reasons only they understand :-) particular versions of, say, GNU
Emacs and gcc installed.

> I don't think that libtool is the right vehicle for you to evangelise your
> dislike of packaging systems and the FHS.

But debian-devel is probably a good place to talk about these ideas.

> What is available, is a distribution with well-thought (not arbitrary)
> structure and standards.  A distribution used by many people, although not
> as many as RedHat (which has similar standards in most respects anyway).

I should note that I happen to appreciate both of them.

> Nonetheless, you are refusing to support it.

I'm not refusing to support it.  I'm just inclined to avoid having an
easy-to-use flag to disable explicit hard-coding of library paths

1) it would be hard to make it behave correctly in a portable way (and
libtool would be useless if it were not for being portable);

2) it should not be necessary if you play by libtool rules, i.e., you
pre-declare where libraries are going to be installed and keep them
there forever (or until they're no longer needed);

3) I don't want to regret having introduced a flag that caused as much 
or more trouble than -rpath; and

4) I have already suggested a (dirty and ugly, I admit) hack that is
sufficient for your needs of not using -rpath at all in Debian

I hope you understand my position now.  I should also note that I
myself have already wanted flags such as -hardcode-libdir for
hardcoding the full pathname of a shared library into itself (it's
mentioned in libtool/TODO) and -no-implicit-rpath (which is what you
happen to be asking for), but I have some trouble deciding who should
be responsible for deciding which flags to use for which libraries and
programs.  I feel this decision should be left for the installer of
the package, but such installer-customizations aren't easy to
introduce in the existing installation meta-tools.  I'd really
appreciate if someone had a bright idea about how to do that; I'd just
like to avoid providing such dangerous flags for inadvertent use.

Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
Universidade Estadual de Campinas, SP, Brasil

Reply to: