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

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:

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

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



Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com

Reply to: