On Wed, Jul 28, 2010 at 10:10, Charles Wilson
<cyg...@cwilson.fastmail.fm> wrote:
> Well, after the first 7 of 9 (no star trek jokes, please), in native
> mode, all of the problematic tests pass (old:
> tagdemo-conf.test+tagdemo-make.test; new: 41, 101).
That's good.
> So, I can either squash 8 and 9, and treat it atomically, or refactor
> the division between the two (e.g. squash them, and then split them
> differently). I think I'll do the latter.
Agreed.
> But that doesn't appear to be the case for cross builds, in the
> new tests.
>
> But I don't think it was bisectable in cross builds in your original
> development either.
Yes, I usually develop this way (tests are written and committed
first) and then move the tests last before the final post/push to
preserve bisectability.
> A tree wound to just after the new 7/8, passes all of the problematic
> tests. So, whatever the issue, it is introduced by the new 8/8, which
> at least narrows down the problem.
>
> 1 func_replace_sysroot ()
> 2 {
> 3 case "$lt_sysroot:$1" in
> 4 ?*:"$lt_sysroot"*)
> 5 func_stripname "$lt_sysroot" '' "$1"
> 6 func_replace_sysroot_result==$func_stripname_result
> 7 ;;
> 8 *)
> 9 # Including no sysroot.
> 10 func_replace_sysroot_result=$1
> 11 ;;
> 12 esac
> 13 }
>
> See anything wrong with line 6?
>
> - func_replace_sysroot_result==$func_stripname_result
> + func_replace_sysroot_result=$func_stripname_result
>
> So, with that obvious fix...no change :-(
No! That's exactly how -R=/path is generated! You strip the sysroot
and replace it with an equal sign. Example:
@@ -6386,7 +6402,8 @@ func_mode_link ()
# If the user specified any rpath flags, then add them.
temp_xrpath=
for libdir in $xrpath; do
- func_append temp_xrpath " -R$libdir"
+ func_replace_sysroot "$libdir"
+ func_append temp_xrpath " -R$func_replace_sysroot_result"
case "$finalize_rpath " in
*" $libdir "*) ;;
*) func_append finalize_rpath " $libdir" ;;
Maybe you want to change it to
func_replace_sysroot_result="=$func_stripname_result"
Useless quoting, but perhaps clearer.
> It still fails (native) new:41,101 and old:tagdemo-conf+tagdemo-make. I
> guess some more eyes on the revised 8/8 would be helpful. Well, on all
> of the patches, actually, I guess -- but new 8/8 is the likely locus of
> the bug.
I'd tend to blame more the libtool.m4 part. After all it's what
computes postdeps. What about splitting it further by separating the
ltmain.m4sh (first commit) and libtool.m4 (second commit) changes?
Paolo
