Re: checks using DESTDIR in libtool-1.5.22+ ?

[Ralf Wildenhues]

Hello Michael,

* Michael Haubenwallner wrote on Wed, Jan 24, 2007 at 12:21:48PM CET:
> 
> Using DESTDIR during 'make install' is very common for binary-packagers.
> I've seen some problems on various platforms (mostly hpux and aix),
> which do not appear when installing without DESTDIR.

We have fixed at least one related bug for each of HP-UX and AIX in the
CVS HEAD tree of Libtool.

> So, am I missing something here, or are there no libtool-checks using
> DESTDIR installs at all ?

CVS HEAD has tests/destdir.at.  It's pretty basic so far, but
unfortunately mostly represents what is portably working with Libtool
ATM.

I have some unposted patches for more test exposure, but those bits fail
on some systems now.  As you've had to learn the hard way.  See also
<http://lists.gnu.org/archive/html/libtool-patches/2006-09/msg00017.html>.

It would be helpful to see whether the failures you're seeing are
different cases than the ones I know of.

>      1. $ configure ...
>      2. $ make
>      3. $ make install DESTDIR=./_image

I think in general DESTDIR needs to be an absolute path.  Automake
currently assumes this, otherwise its value would have to be adjusted
for sub-makefiles.  Libtool currently assumes this, too, because it will
complain about non-absolute installation paths.  Hmm, standards.texi
should document this fact...

>      4. $ make clean
>      5. copy "_image/$prefix" to "$prefix"
>      6. remove _image
>      7. run the installed executables from $prefix
> 
> The two cleanup steps (4 and 6) are to check that the installed binaries
> do not depend on libs in build- or image-dir.

Yes.  destdir.at does this.  It also does
       6b. Put false libraries into _image and the build-dir, in order
           to provoke failures if those directories appear in the search
           paths (before the correct directory).

We could still do more, at least on some systems: test that they don't
appear in the search paths even after the correct path.  I think I have
an unfinished independent test for this though.

You are certainly correct in that the test exposure is far too small
right now.  Writing those tests in a way so that they are portably
reliable, i.e., both work reliably if libtool is doing things right
but also provoke failures reliably if not, is tricky and takes time
and lots of testing.

Cheers,
Ralf