cygwin build_alias issue

[Ralf Corsepius]

On Wed, 2004-09-01 at 06:16, Chris Johns wrote:
> Joel Sherrill <joel at OARcorp.com> wrote:
> > 
> > I think I have a hint about this.  My system configures
> > correctly when I explicitly specify a single BSP to configure
> > with (--enable-rtemsbsp=XXX) but fails with the build_alias
> > error when that option is not specified or a set of
> > BSPs is specified.
> > 
> 
> I an not sure if this is related, but it does not hurt to mention it. I 
> found a bug in the MSYS (MinGW) project's port of Cygwin. The bug report 
> can be found here:
> 
> https://sourceforge.net/tracker/?group_id=2435&atid=102435&func=detail&aid=807543
> 
> What I found after a detailed look into the failure is the command line 
> order to configure effected the failure. As the failure was in a nested 
> configure call this order was fixed. The bug was triggered by a call to 
> expr occurring after the --target option processing. It returned the 
> wrong result.
The symptoms match (aborting on the first "option=value" argument passed
to a configure script). 

But ... still nobody seems to have been able to "sh -x" or strace this
issue, ... so all this is wild guesses.

> I know MSYS and Cygwin are not exactly the same code base, how-ever my 
> point is this could be a shell bug.

I still think it's more likely a "resources problem", because the bug
doesn't seem to be deterministically. 

E.g.

* Scott's reports show that this issue pops up at different places, i.e.
at places where configure scripts that were reported to fail in previous
configure runs, must have finished successfully.

* Joel's remark (--enable-rtemsbsp=..) indicates that reducing the
amount of required resources, reduces the likelihood to trip this issue.

So, I am inclined to think, that it's likely expr returning a bogus
return value to be the trigger for these failures, but I doubt this is
the origin.

Ralf