RE: -rpath with libtool and Debian Linux
> -----Message d'origine-----
> De: Alexandre Oliva [SMTP:oliva@dcc.unicamp.br]
> Date: mercredi 27 janvier 1999 22:23
> À: Jules Bean
> Cc: J.H.M. Dassen; debian-devel@lists.debian.org; yosh@gimp.org;
> bug-libtool@gnu.org; libtool@packages.debian.org
> Objet: 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:
>
<snipped>
> > We even support separate versions of software, to some extent,
> although
> > I'd agree completely that our support in this area is not what it
> might
> > be.
>
> 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.
>
Good point. I'm not either using any "standard" packaging system like
rpm or deb, just due to this. I use a (quite primitive :-)) homegrown
packaging system taht allows my users to install each realease in a
different location, anywhere they want on their disk. Period. (I think
difficult to be more opened...)
My problem is that if in my package I create a shared library that will
be used by the exec in this package, and I use libtool for this, then
the use of -rpath for this cause the user to have to install exactly
where I build it (that is in some highly non-standard place due to our
complex development environment), or else the -rpath will point in some
unexistent place and (as Linux will ignore LD_LIBRARY_PATH) I can't
override it...
Not to talk about having to cope with you, Linux packagers, moving
system libraries from release to release :-) But I'm confident your
tools are coherent and that if you move libraries, your linker will find
them in the proper place.
So I think -rpath may be useful INSIDE packages, IFF we use relative
pathnames (that \$ORIGIN I saw in a message yesterday I think), but
should only be used for standard libraries if the OS distributor advised
us to, and NOT USED IF THE CONTRACT I PROPOSE US say NOT TO USE IT!
The purpose of libtool is to help us build portable code, whose built
rules are adapted to the build platform, isn't-it :-), so let's do it:
if Linux distribution maintainers advise us not to use -rpath on their
distribution, we must trust them (and blame them if the solution they
recommend do not work 8-(, but then THEY have to correct their
implementation! :-))
> >> 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?
>
> > Of course not ;-)
>
> Jeez!, I was sure I had added a smiley after that last sentence.
> Sorry about that...
>
> > If you want to test one version, you simply run it with
>
> > ./configure --prefix /home/me/nicepackage
>
> But isn't this exactly what the packaging systems are trying to avoid,
> i.e., that people have to compile systems on their own? And then, how
> could I make sure that my test build works exactly as the pre-compiled
>
> upgrade, so that I could use the packaging system for the update?
>
>
> This is something that I feel that should be taken care of by the
> existing GNU/Linux distributions. In fact, I've got a bunch of ideas
> that I'll probably never find time to implement :-( about how to
> maintain multiple versions of packages installed and allowing each
> user to select which version he wants to use, either by explicit
> version number or by tags such as `stable', `test', `old', etc, tags
> that are determined by the system manager when he installs the
> package.
>
I think this is slightly off topic, or we may have to start a whole new
mailing list to discuss packaging systems (I don't know but I'm quite
sure there exist mailing lists or newsgroups on RPM, DEB, etc. :-)) Here
we are talking about how libtool could help isolate us from the
peculiarities of different OSes, and I think this is enough work :-)
Regards,
Bernard
------------------------------------------------------------------------
------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
------------------------------------------------------------------------
------
Reply to: