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

[Ralf Corsepius]

On Tue, 2004-09-07 at 18:50, Bogdan Vacaliuc wrote:
> 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.

http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.6.1/share/rtems/html/started/started00073.html

> 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
This is the same symptom :-)

> 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'
Exactly, it is a limited shell, not a general purpose shell.

> Also, consider that every one of the configure scripts is tagged with
> #!/bin/sh not #!/bin/bash, but I see your point.
Autoconf scripts are /bin/sh scripts, they do not rely on bash.
/bin/sh is supposed to be a general-purpose, Bourne-shell compatible
shell. Its nominal behavior is covered by POSIX for more than a decade.

Unfortunately, many shells carry bugs, some OS vendors ship ancient
non-POSIX-compliant shells, Cygwin is shipping a limited shell as
/bin/sh, etc.

Autoconf already tries hard to only use portable /bin/sh-contructs (i.e.
shell commands that appear to be safe on all known wanna-be-shells) and
already contains an awful lot of runtimes checks to dynamically adapt
configure scripts to degrade gracefully on shells which are known to be
defect (e.g. zsh-3.x and Solaris' /bin/sh).

I.e. once the origin of this breakdown is known and can be
deterministically reproduced and a work-around can be found, autoconf
might be extended. Until then, there isn't much we can do, but to try
isolating the bug.

Ralf