libtool-patches
[Top][All Lists]
Advanced

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

Re: DESTDIR install on hppa-hpux


From: Michael Haubenwallner
Subject: Re: DESTDIR install on hppa-hpux
Date: Fri, 05 Jun 2009 09:43:38 +0200

On Thu, 2009-06-04 at 23:45 +0200, Ralf Wildenhues wrote:
> * Michael Haubenwallner wrote on Thu, Jun 04, 2009 at 01:35:11PM CEST:
> > On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote:
> > 
> > > > The most important part of the fix is already suggested in comments
> > > > around 'hardcode_minus_L=yes', as the encoded library path is used as
> > > > fallback location for a specific library when runpath lookup fails.
> > > > As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L
> > > > can safely be set to 'no' IMO, opening the door for DESTDIR support.
> > > 
> > > Hmm.  This does open a small security issue, no?  Imagine the following
> > > setup: user joe compiles some package, then uses 'sudo make install' to
> > > install it in a system location.  First issue: the path to the
> > > compilation location is revealed in the installed libraries and programs
> > > which have dependencies to newly-installed libraries.  Second, if those
> > > deplibs are removed for whatever reason, then the runtime linker will
> > > search in joe's build tree for the shared libraries.  This may not be
> > > likely to happen, but it's something to think about.
> > 
> > I've thought about this too, but how would the link command have to look
> > like to avoid this issue?
> 
> I don't know.  That's precisely the reason we haven't gone this way
> before.

Ah, I see.
Hmm, I'll have to keep a patch myself then, as using DESTDIR is a
blocker here...

So the 'chatr' hunk in the test also must not ignore the fallback path
then. But it still helps for cc/aCC, as they both encode the commandline
into each object file leading to false positives otherways.

> > > > Another minor one was that there is no need to pass
> > > > "+b $install_libdir", as the linker ignores subsequent "+b" values.
> > > 
> > > Erm, libtool has code to merge multiple run path values (and to let
> > > ltmain know that this needs to be done).  Weren't semantics on HP-UX
> > > that way that, if +b was not used, then the linked path with -L is
> > > searched too?  That would be bad then.
> > 
> > This is done anyway using $hardcode_libdir_flag_spec.
> > Leaving "+b $install_libdir" in $archive_cmds would ignore the
> > subsequent collected "+b $libdir".
> 
> Oh.  So I guess this would be an independent fix anyway?

Hmm, could be indeed.

The 'chatr' part definitively is independent too, although with above
mentioned change.

Thanks!

/haubi/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]