This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)

On Sun, Sep 12, 2004 at 09:42:07PM -0400, Bogdan Vacaliuc wrote:
> Hello again,
> After (finally?!) noticing that a new release of the cygwin.dll was made on Sept. 4 and being encouraged by the line:
> "- Fix mysterious configure script premature exit.  (Pierre Humblet)"
> I decided to check against the latest public release.  The problem continues to persist, unfortunately.
> I created a simplified testcase, by realizing that a simple will let autoconf generate a suitable configure script.
> This auto-generated configure script exhibits the argument parsing failure as readily as any script taken from a build environment.
> It is also attached (as text this time, sorry for all the compressed business I mucked with previously).
> Here is the file needed for autoconf:

The reason the mysterious configure script premature exit got fixed is that
we got a SIMPLE test case. Running a long configure script myriad times,
looking for an elusive error, won't lead to fast progress.
So try to isolate the error and produce a small test case.

I looked at the bashstracesnip2 trace provided by Peter Ekberg in
I believe he is chasing the same problem as you.

The error occurs in the snippet
 -with-* | --with-*)
    ac_package=`expr "x$ac_option" : 'x-*with-\([^=]*\)'`
    # Reject names that are not valid shell variable names.
    expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null &&
      { echo "$as_me: error: invalid package name: $ac_package" >&2
   { (exit 1); exit 1; }; }
The surprise is that the error message:
"configure: error: invalid package name: extra-includes"
is produced at time 29722848 by bash 2624 (the main script pid).
This is BEFORE the second expr is exec'ed. This occurs only at
time 29725911 by a forked child 2656 of 2624
Following the output of the error message, 2624 proceeds to fork
2384, which apparently does nothing. 2624 then waits for
2656 and 2384 and exits.

In other words the control flow seems to be seriously screwed up.
It may be linked to the pid reuse problem in bash, but I know very
little about it. Looking at the full trace available from 
Peter may help.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]