Re: -rpath with libtool and Debian Linux
On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote:
> > 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.
Please start another thread under a different subject for this. It is an
important but mostly unrelated topic.
> > 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);
So why not move the discussion in a direction where we can talk about
portability, instead trying to convince each other that the own ideas are
the best. We are faced here with two different ideas about library
dependencies (handling them at compile/installation time on your side,
or handling them at run time on our side), so we better talk about a way how
to address both.
IMHO, both have their positive and their negative. Now let's try to get
constructive.
> 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);
See above. Libtools rules are not necessarily the only "true" rules. Let's
try to get support for diversity in library handling.
> 3) I don't want to regret having introduced a flag that caused as much
> or more trouble than -rpath; and
I don't understand this comment. Which "trouble" with "--rpath" do you mean?
Until now, I only heard from you that rpath is the ideal solution. Maybe we
can get a better understanding of each other when we outline the negative of
the own solution. I'll try a beginning:
No rpath makes it harder for the linker to find the library. In fact, on
some systems, it may make it impossible, so rpath is essential on some
systems (though not GNU/Linux or GNU/Hurd). On other systems, the linker
needs some smart way to resolve dependencies and search for libraries.
No rpath makes it harder for a user to determine exactly which system
libraries he links with. (With rpath, though, it only works when the system
administrator never changes the library file at this place, too).
This is in a hurry. Could you do me tha favour and list some negative points
of using rpath, too?
> 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.
We can find our own hacks (and do so since a long time). Now we are
interested in a compatible, portable and general solution. As the libtool
maintainer, you should be the ideal person to talk about such a solution.
I think we understood by now that a simple disable flag does not satisfy
your high ambitions wrt to portability. Let's move on to better solutions.
> 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.
Maybe you should not be the one to decide at all? Offer flexible solutions,
where the last person can override the (possible) default given by others.
This means, the package can provide a default, which can be overridden at
compilation time. Finally, the installer can override both.
> 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.
Implement what works and provide a framework for things which should be made
to work. This means, implement those flags for compilation, and
leave installation possible for later.
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: