>
> Duft Markus wrote:
>
> >>> Patches that do more good than harm are likely to be accepted.
> >> That's exactly the point i'm unsure about, if I do more harm than
> good
> >> or the other way round :) of course, for _me_ I do more good, but
> does
> >> it harm others that the hardcode test fails now?
>
> Sorry, don't know how I missed that patch, still, it strikes me as
more
> of a hack than a solution (and what is with the commented case
> statements being added to ltmain.m4sh?).
I wrote about that just in the last mail... the commented thing is to
add a rpath everytime, so that +s gets added...
>
> I'm not even sure how much +s is relevant here, you are changing the
> hardcode_minus_L to no, surely that is having the largest effect on
> your DESTDIR installs, not the +s changes?
I - again - tried to follow the path I took through the libtool sources:
>From destdir.at: (so I need fast_install=yes)
[# DESTDIR installs do not work with relink at install time.
AT_XFAIL_IF([eval `$LIBTOOL --config | grep '^fast_install='`
case $fast_install in no) :;; *) false;; esac])
>From libtool.m4: (so I need hardcode_action != relink)
if test "$_LT_TAGVAR(hardcode_action, $1)" = relink ||
test "$_LT_TAGVAR(inherit_rpath, $1)" = yes; then
# Fast installation is not supported
enable_fast_install=no
Again from libtool.m4: (so I need either hardcode_direct = no or
hardcode_minus_L = no)
# We can hardcode non-existent directories.
if test "$_LT_TAGVAR(hardcode_direct, $1)" != no &&
# If the only mechanism to avoid hardcoding is shlibpath_var, we
# have to relink, otherwise we might link with an installed
library
# when we should be linking with a yet-to-be-installed one
## test "$_LT_TAGVAR(hardcode_shlibpath_var, $1)" != no &&
test "$_LT_TAGVAR(hardcode_minus_L, $1)" != no; then
# Linking always hardcodes the temporary library directory.
_LT_TAGVAR(hardcode_action, $1)=relink
In reality both harcode_direct and hardcode_minus_L are yes on hpux.
This prevents DESTDIR from ever working, since hardcode_action=relink,
and thus fast_install=no, and thus DESTDIR=not working ... :(
This means I need to make one of the two (hardcode_direct or
hardcode_minus_L) "no". hardcode_minus_L is true, because the linker
hardcodes the -L as the _default_ path to the lib, which means it is
taken into account as a last resort. In libtool.m4 there is this
comment:
# hardcode_minus_L: Not really in the search PATH,
# but as the default location of the library.
Which makes me believe, that switching hardcode_minus_L is still wrong,
but should work for all cases except for when there is no other path
encoded anywhere, right?
I now changed my patch, and removed all the +s stuff from it, so there
are only two hunks left, changing hardcode_minus_L to yes. The classic
Testsuite runs through, except demo-hardcode.test again of course, which
detects the hardcode_minus_L "wrong" setting. The Autotest-suite has as
many FAILED as always :) but now the destdir.at tests succeed. The new
patch looks like this:
diff -ru -x 'configu*' -x 'config.*' -x 'Make*' -x '*cache*' -x
'aclocal*' -x 'acinclude*' -x '*doc*' -x ltmain.sh
libtool-2.2.4.orig/libltdl/m4/libtool.m4
libtool-2.2.4/libltdl/m4/libtool.m4
--- libtool-2.2.4.orig/libltdl/m4/libtool.m4 2008-08-22 10:07:34
+0200
+++ libtool-2.2.4/libltdl/m4/libtool.m4 2008-08-25 08:23:40 +0200
@@ -4777,7 +4777,8 @@
# hardcode_minus_L: Not really in the search PATH,
# but as the default location of the library.
- _LT_TAGVAR(hardcode_minus_L, $1)=yes
+ _LT_TAGVAR(hardcode_minus_L, $1)=no
+
;;
esac
fi
@@ -5707,7 +5708,7 @@
*)
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
- _LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search
PATH,
+ _LT_TAGVAR(hardcode_minus_L, $1)=no # Not in the search
PATH,
# but as the default
# location of the library.
;;
>
> This patch is not acceptable as is, sorry.
Yeah, I thought so... Suggestions?
>
> By the way, do you see DESTDIR installs failing for every package on
> hppa-hp-hpux systems?
I don't really know, since a colleague gave me that problem. We need
DESTDIR for portage to work, and obviously even if it would be only some
cases, it would be too many of them. The destdir tests in libtool
testsuite are skipped by default, since they have no chance to ever work
it seems.
Cheers, Markus
>
> Peter
> --
> Peter O'Gorman
> http://pogma.com
