Re: DJGPP support in Autoconf

[Eli Zaretskii]

> Date: Sun, 13 Sep 2009 21:12:30 +0200
> From: Ralf Wildenhues <address@hidden>
> Cc: address@hidden, Rugxulo <address@hidden>,
>       Reuben Thomas <address@hidden>
> 
> 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:
> <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

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.