[Top][All Lists]

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

Re: Cygwin patches from Charles

From: Gary V. Vaughan
Subject: Re: Cygwin patches from Charles
Date: Fri, 14 Nov 2003 11:15:58 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3

Hash: SHA1

Charles Wilson wrote:
| 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.

Hmm.  I'm none the wiser, as you suspected :-(  Perhaps the testsuite is
running an older installed libtool if the current one is not yet built, or
something similar?

I certainly have only very recent (several weeks at the most) old libtools
installed on my machines, and I haven't seen these failures for a long time.

If you come up with a reliable recipe for forcing these errors, I'm really
keen to get to the bottom of the matter.

Thanks for your help!
- --
~  ())_.  Gary V. Vaughan    gary@(|
~  ( '/   Research Scientist       ,_())____
~  / )=   GNU Hacker  \'      `&
`(_~)_   Tech' Author   =`---d__/
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


reply via email to

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