[Top][All Lists]

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

Re: [1.5.26] new test using 'make install DESTDIR=...'

From: Michael Haubenwallner
Subject: Re: [1.5.26] new test using 'make install DESTDIR=...'
Date: Mon, 17 Mar 2008 09:49:01 +0100

On Sat, 2008-03-15 at 18:36 +0100, Ralf Wildenhues wrote:
> Hello Michael,
> * Michael Haubenwallner wrote on Fri, Mar 14, 2008 at 05:53:48PM CET:
> > 
> > as I still encounter problems with libtool-1.5.26 and "make install
> > DESTDIR=...", from 'depdemo-inst.test' I've derived a new
> > 'depdemo-instd.test', simply installing depdemo via DESTDIR.
> > Attached is a patch to add this test for libtool-1.5.26.
> Thank you for the patch.  Is there anything keeping you from moving to
> Libtool-2.2?

I'm working on gentoo-alt/prefix (using portage on different platforms
into some prefix as non-root), so I'm not really a package maintainer.
Sometimes we just apply libtool patches in-place, sometimes we need a
full autoreconf, but I haven't tried yet if it works smoothly for a
package originally using libtool-1.5 to be libtoolized with libtool-2.2.
Is it intended to have this working smoothly ?

>   If no, could you be bothered to redo this for 2.2?  If
> you don't have time, I can do it but it may be a while.  Note that I
> don't have a problem with still adding patches to branch-1-5, but I'm
> not sure whether there will be a 1.5.28, and independently of this
> question we should ensure HEAD does not have any regressions over
> branch-1-5.

I don't really care for another 1.5 release, basically just want to have
some agreement on the patch to know I'm on the right way - and in case
there is another 1.5 release I can drop this patch.

> Note also that 2.2 already has a couple of DESTDIR-related tests in
> tests/destdir.at.  But more test exposure certainly cannot hurt.
> Thanks for your efforts.
> > It simply works when using something like the second attached patch to
> > fall back to "guess we'll fake it" (like all my other platforms),
> > although hardcode_direct IMHO is generally a bad idea when some RUNPATH
> > can be encoded, even without using DESTDIR.
> We've put some fixes in HEAD for this, notably for AIX and OpenBSD.

Is there a release containing them already ?



reply via email to

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