bug-libtool
[Top][All Lists]
Advanced

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

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


From: Michael Haubenwallner
Subject: [1.5.26] new test using 'make install DESTDIR=...'
Date: Fri, 14 Mar 2008 17:53:48 +0100

Hi,

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.

When adding this after depdemo-static, depdemo-conf, depdemo-nofast and
depdemo-shared, on platforms where I can test results are:

  build/host-triplet       static    conf    nofast    shared
---------------------------------------------------------------
  i686-pc-linux-gnu         PASS     PASS     FAIL      PASS
  i386-pc-solaris2.10       PASS     PASS     PASS      PASS
  sparc-sun-solaris2.9      PASS     PASS     PASS      PASS
  ia64-hp-hpux11.23         PASS     PASS     PASS      PASS
  powerpc-ibm-aix5.3.0.0    PASS     SKIP     FAIL     *FAIL*
  hppa2.0w-hp-hpux11.11     PASS     FAIL     SKIP      FAIL

Ok, failing on hppa2.0w-hp-hpux11.11 is less surprising currently.
More interesting is failing on linux with nofast...

But I'm focussing on 'conf' and 'shared' now, because they are the ones
being normally used AFAICT, so my current problem is 'shared' on
powerpc-ibm-aix5.3.0.0:

Here the problem is around line ltmain.in#2804, when one shared library
needs another in-package shared library:

2803         # Finalize command for both is simple: just hardcode it.
2804         if test "$hardcode_direct" = yes; then
2805           add="$libdir/$linklib"
2806         elif test "$hardcode_minus_L" = yes; then
               ...
2809         elif test "$hardcode_shlibpath_var" = yes; then
               ...
2815         elif test "$hardcode_automatic" = yes; then
               ...
2822         else
2823           # We cannot seem to hardcode it, guess we'll fake it.
               ...

It is impossible to "hardcode_direct" using "$libdir/$linklib", because
$linklib is not in $libdir yet but in $inst_prefix_dir$libdir.
But hardcoding $inst_prefix_dir$libdir/$linklib is bad either, as
$inst_prefix_dir is not there at runtime lateron.

Remember libtool is configured this way:
  hardcode_direct=yes
  hardcode_minus_L=no
  hardcode_shlibpath_var=unsupported

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.

Thoughts?

Thanks!
/haubi/

Attachment: libtool-1.5.26-instd-test.patch
Description: Text Data

Attachment: libtool-1.5.26-instd.patch
Description: Text Data


reply via email to

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