Date:	Mon, 1 Jan 2001 09:56:14 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	DJGPP Workers Mailing List <djgpp-workers AT delorie DOT com>
Subject:	Re: Two glitches for autoconf 2.49b
In-Reply-To:	<NEBBIOJNGMKPNOBKHCGHOECGCAAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010101093611.3587T-100000@is>
MIME-Version:	1.0
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

On Sat, 30 Dec 2000, Tim Van Holder wrote:

> First off, it includes (help2)man pages for config.guess
> and config.sub. This leads to clashing LFNs (config.x and
> config.1). I can rename these to config_guess.1 and
> config_sub.1, but that makes for non-intuitive names (who
> would run 'man config_sub' to find out about config.sub?).

How are these files called originally?  Is it config.guess.1 and 
config.sub.1?

If you call the files under man/cat1/ config.guess and config.sub, does 
"man config.guess" and "man config.sub" work with the DJGPP clone of 
`man' (v2apps/man13b.zip)?  If so, you don't need to rename.

If that doesn't work, I don't see anything wrong with config_*.1; I did 
that in the Groff port.  If you say this in the README, whoever wants the 
docs will find it.

> Target of redirect is not a filename.
[snip]
> After grepping several source trees, I traced the error message
> to djgpp's src/libc/ansi/stdlib/system.c.

Yes, this is where the message comes from.

> The relevant m4 macro is:
> 
> == start of snippet from m4sugar.m4
> # m4_file_append(FILE-NAME, CONTENT)
> # ----------------------------------
> m4_define([m4_file_append],
> [m4_syscmd([cat >>$1 <<_m4eof
> $2
> _m4eof])
> m4_if(m4_sysval, [0], [],
>       [m4_fatal([$0: cannot write: $1])])])
> == end of snippet
> 
> It seemed to me that the shell here document was the culprit.

Yes.  The internal amulator of COMMAND.COM doesn't support "<<", it 
expects a file name after `<'.

> Now it was easy enough to rebuild m4 with __system_flags set
> to '__system_call_cmdproc | __system_use_shell' (and setting
> my SHELL envvar to $DJDIR/bash.exe

I'd expect that setting SHELL alone will do, even without rebuilding m4.  
__system_use_shell is set by default (see the beginning of system.c), and 
__system_call_cmdproc is irrelevant to this case, since Bash will be 
recognized by the library as a Unixy shell.  Here's the relevant fragment 
from system.c:

  call_shell =
    (sys_flags & __system_call_cmdproc)
    || (!(sys_flags & __system_emulate_command) && _is_unixy_shell (shell));

Your case is the second part of the condition: __system_emulate_command 
is _not_ set in sys_flags, and the shell is a Unixy one.

> instead of $DJDIR/bash, as system() barfs if you leave off the .exe 
> (why?)).

This is documented in the `system's info node: $SHELL should point to the 
program's file name.  The value of $SHELL isn't run through the code 
which tries executable extensions.

> But which is more acceptable: requiring a custom m4 or adding
> 'export DJSYSFLAGS=6' to the scripts of the autoconf suite?

Neither is acceptable, IMHO.  Instead, please make sure that $SHELL is set
to /dev/env/DJDIR/bin/sh.exe before Autoconf's configure script is run. 
One way to do that is to have a batch file which sets SHELL and then runs
the script.  Another way is to have a private config.site file, or some
other file which Bash source's when it runs ./configure. 

If setting $SHELL alone somehow doesn't work, please tell the details.

- Raw text -