Hello Eli, all, we've recently had a bug report about broken support for DJGPP in Autoconf 2.64, see this thread: <http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/6898/focus=6916>
and after that we found your gdb/config/djgpp/config.sed: <http://sourceware.org/ml/gdb-patches/2009-09/msg00119.html> <http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/config/djgpp/config.sed?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=src> so now we're trying to fix things; I think it is more sensible to have at least the simple workarounds in upstream Autoconf, so that other packages don't have to replicate your config.sed approach, given that this platform still seems to be used. I've hacked git Autoconf to build and run a large part of its testsuite on DJGPP. Below is a description of some of the issues I've found, and I will reply with a few patches to fix or work around some of the bugs; hope you don't mind being Cc:ed. I'd appreciate if you could take a quick look at things, for sanity and completeness. One question: is there a better way to detect whether we are running under DJGPP than test -n "$DJGPP" preferably more reliable but with as few forks as possible? The attentive reader may note that I'm not addressing several bits found in config.sed; I didn't see them in the testsuite, or they don't apply to Autoconf proper code. Bug reports welcome. (test numbers are as of git Autoconf on 2009-09-06.) Thanks, Ralf DJGPP support in Autoconf ------------------------- -- PATH_SEPARATOR is detected wrongly. This can be fixed with a config.site file or by exporting the variable beforehand: export PATH_SEPARATOR=';' Apparently DJGPP has setups for both ':' and ';' so hard-coding it in Autoconf does not seem sensible; the test for it is broken on DJGPP. -- Perl Fcntl::flock does not work. Patch: <http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/6799> -- Frozen files do not work. I think this is probably all due to the list of all characters in lib/m4sugar/m4sugar.m4:m4_cr_all which, when saved in a frozen *.m4f or traces.m4 file is borked. Anyway, line feed gets messed up and some other characters are not printed at all, and then the file ends prematurely, so I assume m4 or some emulation code has died. In the builds, I worked around this by adding -M to lib/freeze.mk:MY_AUTOM4TE make && rm lib/*/*.m4f && cd testsuite && make testsuite && ./testsuite However, autoupdate still doesn't work that way, because one of the trace files contains m4_cr_all text. I don't yet know of a good way around this. Test failures failing in autoconf: 9 Test failures failing in autoupdate: 20-28 259-261 270-271 319-330 335-344 355-357 365-368 390-396 -- Missing POSIX support in DJGPP causes: | -autom4te: m4 failed with exit status: 1 | +autom4te: m4 exited abnormally Test failures: 3 37 39 40 45 57 61 These tests pass if I hack FileUtils.pm to output the same error message. -- Failures due to some obscure DJGPP shell bug with 'return $ac_retval' worked around with patch. Test failures: not recorded (several instances though) -- shell issues with white space in file names (not analyzed): Test failures: 5 32 -- 'test -f /dev/null && test -r /dev/null' returns true, but '. /dev/null' does not work. Worked around with patch. Test failures: 14 31 259-261 270-271 284-287 -- ./script: redirection error: Bad file descriptor (EBADF) or other I/O error Test failures, untreated: 88 195 Test failures due to redirection of fd 1 in configure: many, (worked around with patch) -- leftover 'conftest' files in state-ls.after Bug in Autoconf, fixed with patch. Test failures: 254 256-257 280-283 288-289 298 -- segmentation faults in configure or config.status, not analyzed Test failures: 205 210 218-219 242 349-352 360 363 -- hangs, wild 'find' runs across the file system, or other unanalyzed failures: Test failures: all matched by '-k autotest', 93-94 110-186 -- as_ln_s setting wrong? Test failures: 349-352 -- needed to move GNUmakefile out of the way.
