Subject: Re: Win2k + djgpp
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com, perl5-porters AT perl DOT org
In-Reply-To: <7458-Mon10Sep2001233119+0300-eliz@is.elta.co.il>
References:  <001201c13a17$20353020$747d76d5 AT pandora DOT be> 
	<7458-Mon10Sep2001233119+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13.99+cvs.2001.09.07.02.46 (Preview Release)
Date: 11 Sep 2001 08:37:05 +0200
Message-Id: <1000190227.3781.5.camel@bender.falconsoft.be>
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
Precedence: bulk

On Mon, 2001-09-10 at 22:31, Eli Zaretskii wrote:
> > From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> > Date: Mon, 10 Sep 2001 18:39:13 +0200
> > > 
> > >   base/cond......c:/util/djgpp/tmp/dj310000: Cannot duplicate 
> > > fd 1: Bad file descriptor (EBADF)
> > >   FAILED at test 0
> > 
> > There's a known problem with file descriptors perl-spawned
> > programs (present in 5.6.0, 5.6.1 and 5.7.2), which prevents
> > autoconf > 2.50 from functioning under DJGPP.  I've yet to find
> > either cause or solution (Laszlo, you have any idea?).  A test
> > case is attached - run normally, foo.exe will allocated
> > FDs 5 - 19 for the testfiles; if run from the perl script, it
> > gets FDs 3 - 17 (and 3 and 4 are not supposed to be used, IIRC).
> 
> Why is this a problem, and how does it cause the EBADF failure?
> 
> I don't think a program (Perl in this case) should assume anything
> about the descriptors that are preconnected, beyond the standard 3
> ones.

Well, if you recall there was an issue where a perl-spawned shell
script (for example, autoconf when called from autoupdate) could
do
  exec 4>config.log
but any redirection to FD 4 would cause EBADF.  The same script would
work just fine if run from the shell.
More recently, autoconf's autom4te perl script fails because it
runs 'm4 --error-file=foo'; m4 opens foo (getting FD 4 most of the
time), and any writes to that file are sent into oblivion (the file
is created, but empty).
Now that I know what to check, I'll try commenting out the closing
of stdaux and stdprn and see if that has any effect on it.