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

[Bogdan Vacaliuc]

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

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
(i686-pc-cygwin)):

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

running /bin/bash
/home/bvacaliuc/projects/rtems/rtems-4.6.1-jtm-20040815/c/src/tests/tools/ge
neric/configure  '--prefix=/home/bvacaliuc/projects/rtems/install'
'--with-target-subdir=mips-rtems'
'--exec-prefix=/home/bvacaliuc/projects/rtems/install/mips-rtems'
'RTEMS_BSP=csb350' 'RTEMS_CPU_MODEL=au1x00' 'RTEMS_BSP_FAMILY=csb350'
'CPU_CFLAGS=-mips32 -G0 -msoft-float' 'CFLAGS_OPTIMIZE_V=-O2 -g'
--cache-file=/dev/null
--srcdir=/home/bvacaliuc/projects/rtems/rtems-4.6.1-jtm-20040815/c/src/tests
/tools/generic
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
implementations.
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:

http://www.cygwin.com/ml/cygwin/2003-05/msg01094.html
http://www.cygwin.com/ml/cygwin/2003-12/msg00978.html

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:
http://lists.gnu.org/archive/html/bug-bash/2002-08/msg00051.html

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
May-20-2003).

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

Hopefully, these results will wrap this thread up.

-bogdan