Re: Cygwin patches from Charles

[Charles Wilson]

Gary V. Vaughan wrote:

> > Oh -- and one other: non-deterministic behavior in the test suite.  On a 
> > clean build, I'll run the test suite and most tests pass but a few will 
> > fail.  (e.g. mdemo-static fails, and the next four tests in that "group" 
> > are skipped).  But then, upon re-running the affected group of tests 
> > manually, they will often succeed.  This is not a new problem, and 
> > appears to only occur in the testsuite itself -- I haven't seen any 
> > similar non-deterministic bootstrapping behavior ("fails, fails, 
> > works!") in actual packages intended for distribution.  As I said, not a 
> > showstopper and not a new problem.
>
>
> Bugger.  I really thought I had fixed that when I overhauled the
> testsuite :-(  I haven't seen the bogus failures on my mac since then...
> can you send me a verbose trace if you catch it again please?

Here it is, using CVS HEAD on 2003-11-10.  The first time thru, it failed:
  quote.test,
  cdemo-shared.test
  demo-shared.test
  depdemo-relink.test
  mdemo-shared.test
But the quote and depdemo-relink failures are longstanding issues; the 
important ones are the cdemo-shared, demo-shared, and mdemo-shared tests.

Unfortunately, I do not think the log will show you very much, but it is 
attached (libtool-devel-1.5a_20031110-1.check.gz)

Then, I reran the affected tests (and the succeeding ones in each group 
that were previously skipped).  This time cdemo-shared (and following) 
passed, as did demo-shared (and following).  However, mdemo-shared 
failed again.  These results are attached 
(libtool-devel-1.5a_20031110-1.check2.gz)

Finally, I reran mdemo-shared (and following) a third time.  This time 
it passed.  These results are attached as 
libtool-devel-1.5a_20031110-1.check3.gz

I don't see the evidence in these logs, but I vaguely remember that the 
last time I investigated this, I looked at the config.log file 
immediately after the failure.  IIRC, there was an error running the 
configure script: it complained that '--disable-static' was an invalid 
feature name.  e.g.

  -disable-* | --disable-*)
    ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'`
    # Reject names that are not valid shell variable names.
    expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null &&
      { echo "$as_me: error: invalid feature name: $ac_feature" >&2
   { (exit 1); exit 1; }; }
    ac_feature=`echo $ac_feature | sed 's/-/_/g'`
    eval "enable_$ac_feature=no" ;;

But, of course, there's nothing wrong with that block of code, and 
--disable-static is a perfectly valid option.  Which is when I decided 
to go back to work on my thesis. :-)

Now, I can't confirm that the current behavior is the same as this 
earlier episode, since I don't have the config.logs.  But, everything 
ELSE matches the previous episodes, so I think it's a pretty good bet.

--
Chuck

libtool-devel-1.5a_20031110-1.check.gz
Description: GNU Zip compressed data

libtool-devel-1.5a_20031110-1.check2.gz
Description: GNU Zip compressed data

libtool-devel-1.5a_20031110-1.check3.gz
Description: GNU Zip compressed data