cygwin configure problem

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> 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).

What made me think to try this was wondering if config.guess was
reporting a host type that didn't match somewhere.  The x86 is
a constant battle to add 1 to N in iN86.  My config.guess result
is i686-pc-cygwin so that is OK.

> 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"]

According to a post from 2000, Cygwin 1.14 has a limit of 128 processes
but the then upcoming 1.1.5 had no limit.  I think any release in the
past couple of years would be OK.

http://sources.redhat.com/ml/cygwin/2001-04/msg00141.html mentions
a 128 MB limit on heap chunks and a registry key to change.  Doesn't
seem like that would be likely does it?

http://www.cygwin.com/ml/cygwin/2000-03/msg00450.html is part of a
thread discussing open file limits.  Looks like 20 per process under
Win95/98 and no limit under NT and newer though.



> 
>>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.

I will send this to you separately.

> Even more helpful would be a recursive strace :-)

strace on cygwin doesn't work for me on configure.  It says
it got an error 193 creating the process configure.  I tried
it on a "bash -x ..." of it and got the same error.  It works
when I invoke it on who.  Any ideas?

>>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?

Yes.  I used "m68k-rtems-gcc j.c" and got a m68k ELF file named a.out 
which I tried to execute.  Windows politely ran it and reported a weird
error message.


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

definitely.

> Ralf.

--joel