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
because:
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
packages.
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}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: