On 7/28/2010 5:05 AM, Paolo Bonzini wrote:
> On Wed, Jul 28, 2010 at 10:10, Charles Wilson
>> 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.
Hmm. Should I pull the comments added to sysroot.at by
handle-sysrooted-paths-when-reading-dependencies-to-.patch
merge them into the earlier
add-a-basic-sysroot-test.patch
and then reorder so that add-a-basic-sysroot-test.patch is once again last?
>> 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:
...
> Maybe you want to change it to
>
> func_replace_sysroot_result="=$func_stripname_result"
>
> Useless quoting, but perhaps clearer.
D'oh. I blame late night coding. Yes, I'll revert my change, and use
the useless quoting instead.
>> 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?
OK. New results after the (first commit) but before the (second commit):
Interesting. In this case, old:tagdemo-conf+tagdemo-make pass, new:101
passes, but new:41 fails.
That is, the postdeps in libtool are created correctly (e.g. the problem
with not extracting the postdeps is, as you suspected, in the final
libtool.m4 change).
However, it's the ltmain.m4sh part that breaks new:41. The symptoms of
the breakage, with and without the libtool.m4 part, are the same. From
testsuite.dir/041/testsuite.log:
../../libtool-sysroot/tests/runpath-in-lalib.at:61: grep /foobar
$libdir/liba.la
stdout:
../../libtool-sysroot/tests/runpath-in-lalib.at:61: exit code was 1,
expected 0
41. runpath-in-lalib.at:25: 41. Runpath in libtool library files
(runpath-in-lalib.at:25): FAILED (runpath-in-lalib.at:61)
--
Chuck
