[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cygwin build_alias issue
- Date: Wed, 01 Sep 2004 07:07:53 +0200
- From: ralf_corsepius at rtems.org (Ralf Corsepius)
- Subject: cygwin build_alias issue
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:
> 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.
* 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