Den 2010-09-09 22:05 skrev Charles Wilson: > 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.
Both 6/7 and 7/7 are outstanding. Both relate to running a Win32 native toolchain in Wine or in Cygwin and are in my "priority 3" category if you remember my classification (1 gnu, 2 msvc on msys). So not very important for the pending release, but still nice to have of course. I'm sure Christopher likes them though, as he does not want to use MSYS. For 6/7 (several $NM invocations) testsuite coverage was requested. If this patch is revised to use the new LAZY argument, the patch will have even less impact. But it will also require a weirder setup to tickle the new code. For 7/7 (prefer $NM @file) Ralf suggested that we should keep to the current scheme as much as possible and not use the @file branch unless needed as the @file branch made debugging harder. Since the @file branch is also slower on MSYS it should probably be avoided there for that reason too. But the current primary scheme only works when to_tool_file_cmd is a noop (and on MSYS) when facing absolute file names, so something needs to be done. Other than that, I have two identified testsuite weaknesses that could be fixed, but that's not very important at all. Look at the above as a status report written since there seem to be confusion in that area. I intend to post new messages with more exact info on what I want to happen with the outstanding 6/7 and 7/7 patches. But not today. >> 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... See above. >> 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 adjusted both reconfdirs and TESTS. You tend to learn how to do that quickly in windows-land. The payoff for that learning curve is almost instantaneous. > 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. In my current setup it's hard to automate, as I do git and bootstrap on Cygwin only, then test Cygwin and when that is done I switch to MSYS and test there too. I have version mismatches for automake and autoconf in MSYS and Cygwin, so if I'm not careful things go belly up. I should perhaps try to have matching autotools, but I'm used to not having them at all in MSYS, and I'm not sure if things will be screwed up with paths leaking in from the other posix world if I mix, so I'm just doing it in a way that I know works. >> 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. Watch out, rant coming up. You have been warned. My problem(?) is that libltdl issues are the hardest to fix, so there are multiple issues that are not fixed for MSVC. That, and that most libltdl tests are too wide for my liking, so the libltdl part of the testsuite tend to either be all failing or all failing even if you have made an improvement. Which makes it hard to use the testsuite to determine if you have made any progress when you are testing something. It is also hard to deduce if you have caused some spectacular new fail with a patch, if the test in question fails before it got to the newly introduced badness. Even if the the new fail happens before the old fail, it's still harder to discriminate fail:63 from fail:67 than it is to discriminate fail:63 from ok. It also doesn't really help that I'm not using libltdl for anything real: I'm not really familiar with what the expected behavior is and it tends to not be that important and "itchy" to me. And then, as always, there's the wall clock issue. You can have many ideas while you are waiting for the testsuite, and when it finally finishes you have forgotten what it was you were thinking when it started, which also makes it harder to connect the new results with those old ideas. Similarly if you have moved on to something completely different before you get the results, which is perhaps the more common scenario. I'd like to have more immediate feedback, but that's just wishful thinking of course. It's just painful and there's no fix in sight, everybody knows it, and I don't know why I bother knocking in this open door. stresstest is now ok for MSVC, so it is finally really useful in detecting regressions, and no longer a "masking failure rat hole". Cheers, Peter