Date:	Tue, 10 Mar 1998 15:42:52 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc:	djgpp AT delorie DOT com
Subject:	Re: Rebuilding config.in in gcc-2.8.1
In-Reply-To:	<350529AD.58F8@rug.ac.be>
Message-ID:	<Pine.SUN.3.91.980310152913.4739D-100000@is>
MIME-Version:	1.0

On Tue, 10 Mar 1998, Vik Heyndrickx wrote:

> I'm trying to build the (gnu released) gcc-2.8.1 compiler package using
> djgpp 2.8.0. using the standard method.

I didn't yet try to build GCC 2.8.x, so take the following with a grain 
of salt.

> Autoheader writes its output to a temporary file of the form autoh?????
> At last it is 'mv'-ed to config.in. And THAT FAILS with NEXIST.

NEXIST?  What's that?  Maybe EEXIST?  Or ENOENT?

> Typing the exact same mv command at the command line DOES succeed.
> 
> I tracked down the reason up to the DOS call level and it seems that in
> _rename that call fails with error code _DOS_EACCESS.

What happens if you replace "mv foo config.in" with something like this:

	mv -f foo config.in || cp -f foo config.in

Does this help?

> At that time no config.in exists and autoh????? does exist. I've not a
> clue why this happens.

One possible reason might be that the destination file name is more than 
8 levels deep under the root directory.  (This only happens on plain DOS.)

Another possible reason (on Windows 95 only) might be that you have an 
old port of `mv'.  Please make sure you have the latest Fileutils port 
(circa December 1997).

> The only reason I can think of is that the
> autoh????? file is still open by some process, and since the only
> process still running is bash, could this be a bug in bash?

I find it hard to believe.  First, Bash has no reason holding a file 
open, since it doesn't read or write it at that point (if I understand 
the situation correctly).  And second, every time I suspected Bash to be 
responsible for some weird behavior, it turned out to be someone else's 
(guess who's) fault.  (I'm talking about almost two years of experience 
running complex shell scripts.)  This doesn't prove anything, but it does 
tell something about the quality of the Bash port (thanks a lot, Daisuke 
Aoyama!).

Of course, you should make sure you have the latest port of Bash.

If nothing else gives a clue, insert "set -x" somewhere before the 
command that fails and watch carefully what commands does Bash run.

- Raw text -