cygwin configure problem

Ralf Corsepius ralf_corsepius at
Thu Aug 19 04:37:22 UTC 2004

On Wed, 2004-08-18 at 19:09, Joel Sherrill  wrote:
> Gene Smith wrote:
> > Ralf Corsepius wrote, On 08/17/2004 09:44 PM:
> > 
> >> On Tue, 2004-08-17 at 19:23, Smith, Gene wrote:
> >>
> >>> Ralf Corsepius wrote, On 8/17/2004 11:47 AM:
> >>>
> >>>
> >>>> On Tue, 2004-08-17 at 17:16, Smith, Gene wrote:

> >>> configure: error: invalid variable name: build_alias
> >>> configure: error: /bin/sh
> >>> '../../../../rtems-4.6.1/tools/cpu/generic/configure' failed for generic
> >>> configure: error: /bin/sh '../../../rtems-4.6.1/tools/cpu/configure'
> >>> failed for tools/cpu
> >>
> >>
> >> This issue had been reported many times (Please check this list's
> >> archives).
> >> I am not using Cygwin myself, and therefore hardly can help, but AFAIU
> >> the Cygwin users' reports, this is a bug in Cygwin.
> The PC I am using today has a fairly recent but not completely current
> Cygwin installation and it exhibits this problem when Norton AntiVirus
> is enabled or disabled.
> If I specify --build=i386-cygwin on the top level configure, I managed
> to get configured but when it finished doing configure as part of make,
> it failed with the build_alias message.
Hmm, the essential difference in explicitly specifying --build and not
explicitly specifying it, is the way the build_alias shell variable
inside of the toplevel configure is set up. Not specifying --build calls
config.guess, while specifying it does not (search for config.guess and
ac_config_guess in configure for details).

Makes me wonder if we might be hitting some "max. processes", "max.
files/buffers", "max. stack size" or similar issues on Cygwin/Win.
[I am thinking along the lines of processes temporarily not properly
deallocating resources - something like "transient zombies"]

> I can provide the "bash -x" log of a failed configure if anyone
> cares.
Yes, this would be helpful. Though this problems has been frequently
reported, I don't remember ever having seen an "sh -x"-trace.

Even more helpful would be a recursive strace :-)

> Interestingly, I built a test m68k executable of "main() {}" and
> tried to run it with NAV enabled and it was allowed with no
> NAV messages.
built? Do you mean you invoking the compiler worked?

Well, this spawns far less processes and involves far less tools than
configuring the source tree :-)


More information about the users mailing list