[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cygwin build_alias issue (and a possible workaround...)
- Date: Wed, 08 Sep 2004 11:20:52 +0200
- From: ralf_corsepius at rtems.org (Ralf Corsepius)
- Subject: cygwin build_alias issue (and a possible workaround...)
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
> 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.
> 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'
> '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
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
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.