Date: Tue, 10 Mar 1998 15:42:52 +0200 (IST) From: Eli Zaretskii To: Vik Heyndrickx 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.