Re: libtool-2.4, cygwin: Odd failures

[Charles Wilson]

On 9/24/2010 1:26 AM, Ralf Wildenhues wrote:
> Can you send detailed ls output including full time stamps, right after
> the above failure, for the following directories:
>   top_srcdir
>   top_srcdir/libltdl
>   builddir/tests/testsuite.dir/086
> 
> plus the time at which you ran the test.  Thanks.

attached.  It appears this particular test was run around 18:37EDT
thursday, but I can't get any more accurate than that.  I launched the
test suite around 15:30, and it didn't finish until around 20:30.
Judging solely by the timestamps:

drwxr-xr-x+ 1 me Users    0 Sep 23 18:36 081/
drwxr-xr-x+ 1 me Users 4.0K Sep 23 18:40 086/

and the elapsed times:

82. resident modules (resident.at:27): ok     (0m1.901s 0m4.914s)
83. SList functionality (slist.at:24): ok     (0m0.478s 0m0.857s)
84. enforced lib prefix (need_lib_prefix.at:25): ok     (0m3.505s 0m7.526s)
85. compiling softlinked libltdl (standalone.at:31): ok     (0m23.462s
1m11.606s)

I conclude: 18:36 (test 81 finished) + 0:4.9 + 0:0.8 + 0:3.5 + 1:11.6 =
18:37:20.8 (test 86 begins).

Note that all files were stored locally; there were no "network shares"
involved.

> FWIW, I've seen issues with some of these tests as well, but they didn't
> fail with this particular warning.
> 
>> Also, if I re-run the failing tests without changing anything else,
>> 86-88 will pass, but 92,108 won't.  Rerunning 92,108 a *third* time
>> allows them to pass.  After that, all five "failing" tests will continue
>> to pass.
> 
> Well, but *that* is something that typically happens when your system
> clock really was not quite right: after a while, no more files have time
> stamps in the future, then everything starts to work.

This is *the same system* with locally-stored files.  The only way the
clock could be "not quite right" is (a) the file system time stamp
granularity was too coarse -- but NTFS is 100ns, or (b) the clock was
not, actually, monotonic.

If either of those were true, I'd never have been able to pass many
tests at all; yet...I've never seen this pattern with libtool's test
suite until 2.4 (even a week ago git master was fine) -- and nothing but
libtool's source code has changed (I have not installed any cygwin
updates between "working" and "broken" except for a new version of the
mingw**64** cross compiler, but that has no bearing here).

> Not saying that this has to be the case here, but it sure is an
> indicator.
> 
>> This smells to me like somewhere the dependency order got screwed up, so
>> that after several re-build attempts, finally the configure scripts are
>> stable, and will "match" without triggering the error above.
> 
> Another possibility, yes.

Since as far as I am aware, since the only change has been in libtool's
source, and this is new behavior, I suspect libtool rather than
something intrinsic to my (unchanged) system.

>> I'll submit the build logs for the "pristine" 2.4 case on cygwin, with
>> the five failures, in a little while.

I did this last night, but they have yet to show up at
http://autobuild.josefsson.org/libtool/  I suspect if they have not yet,
they never will.

--
Chuck

dirlists.tar.xz
Description: Binary data