cygwin build_alias issue (and a possible workaround...)
bvacaliuc at ngit.com
Tue Sep 7 16:50:14 UTC 2004
> ... 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:
'RTEMS_BSP=csb350' 'RTEMS_CPU_MODEL=au1x00' 'RTEMS_BSP_FAMILY=csb350'
'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