Mail Archives: djgpp/2009/08/25/23:45:37
Hi,
On Aug 21, 8:19=A0am, Andris Pavenis <andris DOT pave DOT DOT DOT AT iki DOT fi> wrote:
>
> Also: do not use autoconf-2.63 if configure is supposed to be run with
> DJGPP port of bash. It has bug which broke configure for
> DJGPP. Bug should be fixed in autoconf-2.64, but I have not tested it.
Previous ZILE 2.3.9 used Autoconf 2.63, and the configure is 668k.
Yes, it has a very minor typo with "\\r" instead of "\r" affecting
config.status. Otherwise it apparently works, mostly (hence my
previously-mentioned Cygwin Autoconf 2.63 usage). With the very-
recently released Autoconf 2.64, they went gonzo for shell functions,
so the configure is now only 438k. And they claim Cygwin is 30% faster
(I doubt it, but anyways ...). But DJGPP Bash has a problem. (Heck,
the only reason ZILE upgraded was I think because I whined that 2.63
had a typo, and he refused to manually fix it.) The Autoconf guys are
hesitant to do any OS-specific workarounds (they prefer targeting
POSIX), and they prefer not to use the DJGPP workaround "( return
$ac_retval )" because that defeats the speed savings of using shell
functions in the first place. But that's the only fix I know
of !! :-/
The problem is apparently some obscure Bash error that has been
reported by Gordon Schumaker as far back as May 2004! (Is he still
around? Didn't you thank him for GCC specs recently?) He was working
on CMake but got stuck with Bash errors (see simplified crash examples
below):
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=3Ddjgpp/2006/08/08/=
16:37:27
Apparently it has something to do with executing something in a
subshell before returning from the function.
Esa Peuha had a theory, but for the life of me I can't understand
where/how/what the heck Bash is doing (very complex source, and I'm
afraid 3.2.48 and 4.0 are probably much more complex). Worse is that
Bash's sources use some CPP macros for setjmp() and longjmp() without
you knowing it (i.e. ctags + VILE / etags + Emacs would probably
greatly help understand everything better by jumping to definitions on
the fly).
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=3Ddjgpp/2006/08/20/=
11:54:36
So the problem is probably in either subst.c or execute_cmd.c, but I
dunno. :-/
Daisuke Aoyama originally ported 1.14.7 (which isn't on DJ's FTP,
oddly), and Mark Elbrecht ported old 2.03, at least. However, they
obviously aren't maintaining them anymore. I still think dash or pdksh
would be loads easier to maintain (assuming it's good enough for
most ./configure scripts), esp. if Debian finally makes dash the
default like I hear they want to do. Heck, I could just ask Chet Ramey
or some other Bash guru for help, but I just blindly assume he's too
busy or not interested in DJGPP (as most *nixers are).
P.S. "set -x" at the top of the script and running "bash --verbose
configure" seems to produce the best output for finding problems (I
think). It might've helped me more at the time, so I'm mentioning it
for others here (esp. since Vista doesn't seem to GPF with useful info
and symify doesn't often work even when it does GPF). There are of
course other problems (Bash 2.04 issues: crashing on install-sh, not
finding gcc, grep, gawk), but I haven't investigated those too much.
- Raw text -