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 _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool