libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.


From: Charles Wilson
Subject: Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
Date: Thu, 09 Sep 2010 16:05:06 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3

On 9/9/2010 3:56 PM, Ralf Wildenhues wrote:
> I understand that you're doing a difficult bug hunt here, and 6/7 is the
> only unapplied patch of this series (right?).  I've looked at 6/7 again,
> and conclude that it has a low chance of regressing.

I agree.

> If it makes things easier for you, then I'm fine with you going ahead
> and applying the patch.

I don't think the uncommitted portions of Peter's series affect this
particular bug hunt (now that the one regression has been corrected).
This one is all me. :-(

OTOH, I'm sure Peter would be very happy to push his remaining patches...

> Secondly, I can help with unsupervised git bisect if you need.  In
> <http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00006.html>,
> I posted a bisect script for a slightly different bug; for your case,
> you should adjust reconfdirs (for efficiency) and TESTS and the failure
> grep.  In the 'git bisect start' command line, you need to specify one
> known-bad and one known-good revision.

I'll take a look, but it may actually be faster to do it old-school:
just trace thru the failing case in git master-NOW, figure out what's
going wrong, and fix it.
 
> Last but not least, IIUC then you've complained about possibly multiple
> failures masking.  Is this specifically about the stresstest?  To
> alleviate this in the future, we can modify stresstest to fan it out
> into several test groups (so separate issues have a higher chance of
> producing separate failures), or modify it so it runs all tests (even if
> some failed earier) and summarizes the failing instances at the end.

Naw, it's not stresstest.  It's just mdemo (and mdemo-2) really push all
the various bits of libtool and libltdl very hard.  It's a very good
test that way.

The problem is we've/I've been too complacent about "known failures" in
that test on MinGW/MSYS.  Sure...it had "known failures" -- but by
ignoring them, more "unknown failures" crept in and were hidden by the
"known" ones.  Now that we're trying to fix it...we discover that the
leftover mashed potatoes in the fridge grew their own mold ecosystem...

--
Chuck



reply via email to

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