X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com Date: Sun, 13 Sep 2009 22:38:15 +0300 From: Eli Zaretskii Subject: Re: DJGPP support in Autoconf In-reply-to: <20090913191226.GA29257@gmx.de> X-012-Sender: halo1 AT inter DOT net DOT il To: Ralf Wildenhues Cc: autoconf-patches AT gnu DOT org, rugxulo AT gmail DOT com, rrt AT sc3d DOT org, djgpp-workers AT delorie DOT com Message-id: <83iqfmzlco.fsf@gnu.org> References: <20090913191226 DOT GA29257 AT gmx DOT de> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Sun, 13 Sep 2009 21:12:30 +0200 > From: Ralf Wildenhues > Cc: autoconf-patches AT gnu DOT org, Rugxulo , > Reuben Thomas > > Hello Eli, all, Added the DJGPP developers list to the addressees. (Will forward the original message in a moment.) > we've recently had a bug report about broken support for DJGPP in > Autoconf 2.64, see this thread: > > > and after that we found your gdb/config/djgpp/config.sed: > > > > so now we're trying to fix things Thanks. > 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. Not all of GDB's config.sed is related to Autoconf. In fact, most of it isn't: most of the changes are there to support building on plain DOS, where we have to cope with the 8+3 limitations of the file names. Various DJGPP tools will automatically adapt themselves at run time, and, for example, generate FOO.i1, FOO.i2 etc. from FOO.texi, instead of the usual FOO.info-1, FOO.info-2 etc. But the Makefiles generated by configure will only reference FOO.info-*, which on plain DOS will not find FOO's Info files. Similarly with y_tab.c produced by Bison instead of y.tab.c, etc. etc. Most of the edits done by config.sed are designed to handle these issues. > One question: is there a better way to detect whether we > are running under DJGPP than > test -n "$DJGPP" It's better to test for $DJDIR. The reason is that $DJGPP is set in the environment by the user that might wish to invoke DJGPP programs from time to time. But its presence in the environment does not yet mean that a DJGPP program is actually running. By contrast, $DJDIR is set by the DJGPP startup code that runs in every DJGPP executable, so if it is present, you can be sure that some DJGPP program is in fact running in that very VM. > -- PATH_SEPARATOR is detected wrongly. This can be fixed with a > config.site file or by exporting the variable beforehand: > export PATH_SEPARATOR=';' The stock version of config.site that comes with the DJGPP port of Bash has a bug: it has the above line, but without quoting the semi-colon. Autoconf 2.64 exposed this because it sets ${PACKAGE_VERSION}, and config.site, for some reason, exports PATH_SEPARATOR only when PACKAGE_VERSION is set. I fixed my private copy of config.site and that solved this problem in GDB. > -- Failures due to some obscure DJGPP shell bug with 'return $ac_retval' > worked around with patch. This is due to a bug in DJGPP ports of Bash 2.03 and 2.04. A patch is known, but it will take time until a patched binary distribution will be available from the DJGPP sites. > -- as_ln_s setting wrong? Configure scripts should use either `ln' (without -s) or "cp -p" with DJGPP, as support for symlinks is only available in the unofficial versions of DJGPP library and tools. I don't know about the other problems, but hopefully others at djgpp-workers will. Thanks again for taking care of these problems.