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

RE: What hack in ld.so?



> -----Original Message-----
> From: Alexandre Oliva [mailto:oliva@dcc.unicamp.br]
> Sent: Sunday, January 31, 1999 12:29 AM
> To: Jason Gunthorpe
> Cc: Debian Developers; bug-libtool@gnu.org
> Subject: Re: What hack in ld.so?
> 
> 
> On Jan 30, 1999, Jason Gunthorpe <jgg@ualberta.ca> wrote:
> 
> > If you wish to make statement that binaries compiled with 
> libtool work
> > only on the host they were compiled for and even then only 
> in specific
> > conditions then fine - but that makes it totaly unsuitable 
> for use by any
> > of the binary distribution maker.
> 
> That's not what I'd like libtool to do.  I agree there is a 
> problem to 
> be fixed, I just think that libtool is not the only piece of software
> that may have to be changed to fix it, because it is not the only
> piece of software that uses -rpath.
> 
> However, there is a risk that dropping -rpath will cause programs not
> to work in hosts other than the one in which they were installed.
> 
> Assume libtool is modified so as to not hard-code directories listed
> in /etc/ld.so.conf.  Then, the Devian (pun intended) distribution adds
> /dev/lib (*) to /etc/ld.so.conf, and configures some of their packages
> to install with --prefix=/dev (wouldn't that be beautiful? :-)
> 
> (*) /dev is for Devian, not devices; I won't tell you that they have
> decided to move devices elsewhere too :-)
> 
> When users of other distributions installed their pre-compiled .dev
> packages, programs that would run on Devian distributions would not
> run in any other, because /dev/lib is not listed in /etc/ld.so.conf,
> and libtool had failed to add /dev/lib to the rpath of Devian
> programs.  Who's to blame for that?
> 
> Of course, the solution is easy: adding the directory to ld.so.conf or
> to LD_LIBRARY_PATH.

There's another solution: Do not use the Devian distribution, and stick
to one of the (hopefully many) distributions of Linux, that happens to
be quite standard :-) 

More seriously, what to describe is building the Devian distribution to
provide something quite special (because if its placed in /dev I presume
it's not available on other distributions), so the .dev packages, that
use this Devian-specific stuff, will antway NOT work on any other
distribution, till the other distribution makers decide to support this
stuff...

And I'm confident in the distribution makers intelligence to put the
Devian-specific stuff in some Devian-compatible ;-) place (that is place
it in /opt/devian because they do not like overloading /dev, and place
/opt/devian in ld.so.conf).

Once more this proves that -rpath is harmful: If Devian use -rpath thsi
will *force* the other distribution makers to place Devian-specific
stuff in /dev (and if Devian was crazy, placing standard stuff in /dev,
their programs will only work on Devian distribution, which may be what
they want but is definitely *NOT* what *I* would like).

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: