Mail Archives: djgpp-workers/2001/09/11/02:38:39
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.
- Raw text -