cygwin build_alias issue (and a possible workaround...)

Bogdan Vacaliuc bvacaliuc at
Tue Sep 7 16:50:14 UTC 2004

Ralf, Everyone,

> ... you should have installed bash.exe as /bin/sh.exe
> (There should be a corresponding entry in RTEMS FAQ or started).

That was exactly the experiment that I tried; and still received the

I checked the FAQ (4.6.1), there is no mention of such a requirement for
cygwin, other than to say that GNU bash is required; so something about the
build process on cygwin should be added after the issues are worked out.

> > though and got the error with expr.log and built-in trace from ash.
> Which would mean, either both bash and ash are affected by a bug
> somewhere else or you do not have bash installed as /bin/sh.exe.

Yes, that is what I was suggesting, and already eliminated the
sh.exe/bash.exe issue this weekend.

I have the results from using bash 3 (GNU bash, version 3.00.0(1)-release

My (single BSP) test-configure-build script ran for *63* successful
iterations before failing with:

running /bin/bash
neric/configure  '--prefix=/home/bvacaliuc/projects/rtems/install'
'CPU_CFLAGS=-mips32 -G0 -msoft-float' 'CFLAGS_OPTIMIZE_V=-O2 -g'
configure: error: invalid variable name: RTEMS_BSP

After having looked at the code to ash (1/27/2004) and bash (2.05 and 3.0),
I can see the following:

1) the use of global 'exit status' variables is common across all
2) bash 3.0 has the most limited use of the global
'last_command_exit_value'; however in cases of signal handling, it still
reverts to a use of it.

You say ash (cygwin's /bin/sh.exe) is widely known to be unsuitable for
building.  I am willing to accept that in the current context; recognizing,
however, that its very existence was designed as a 'limited shell'
specifically for scripting/build environments.  See:

Also, consider that every one of the configure scripts is tagged with
#!/bin/sh not #!/bin/bash, but I see your point.

As far as bash is concerned, here are links to a patch for a bash bug that
appears related to our problem:

Pay special attention to the discussion on how fork()
Both the bash 2 and bash 3 code have support for 'RECYCLES_PIDS'; however,
only bash 3 autoconf defines it automatically for cygwin.  This makes sense,
since the RECYCLES_PIDS patch was not added for cygwin until after
Aug-6-2003 (and the last official patch on the GNU codebase was in

Therefore, based on these reports and based on the evidence that bash 3
(with the RECYCLES_PIDS *defined*) executed my build script for 63
consecutive iterations before failing, the next logical step is to
re-compile bash 2 *with* the RECYCLES_PIDS defined (effectively applying the
patch referenced in 2002-08/msg00051.html above).

As far as the bash 3 failed, however, but I will reserve judgement on that
until this next experiment.  For this I will use a bash 2.05 as both
/bin/sh.exe and /bin/bash.exe which has been compiled with RECYCLES_PIDS

Hopefully, these results will wrap this thread up.


More information about the users mailing list