Message-Id: <199803121754.TAA65036@ieva06.lanet.lv>
From: "Andris Pavenis" <pavenis AT laima DOT acad DOT latnet DOT lv>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Date: Thu, 12 Mar 1998 19:51:18 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Rebuilding config.in in gcc-2.8.1
CC: djgpp AT delorie DOT com, Robert Hoehne <robert DOT hoehne AT gmx DOT net>
In-reply-to: <3507A327.28E2@rug.ac.be>
Precedence: bulk

> Date:          Thu, 12 Mar 1998 09:56:07 +0100
> From:          Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
> Subject:       Re: Rebuilding config.in in gcc-2.8.1

> Eli Zaretskii wrote:
> > It might be that the devil is in the details.  Please post these:
> > 
> >    1) The *exact* command line which is run (by Bash, I presume),
> >       before any expansions (that is, if it includes things like
> >       `pwd` etc., please include them verbatim).
> > 
> >    2) The details of what happens inside the innermost libc function
> >       that fails (`_rename', if I understand correctly), including the
> >       file names it uses and the DOS error codes returned by
> >       `__dpmi_int'.
> 
> The relevant commands I gave (in this order)
> ---------------------
> make maintainer-clean
> del config.in
> del cstamp-h.in
> sh autoconf
> sh ./configure
> make config.in
> ---------------------
> This last line does a "cd . && autoheader"
> (in Makefile, you'll find "cd $(srcdir) && autoheader")
> 
> BTW The configure script from the gnu distribution now works. Thanks,
> Robert! (It was in one of the gcc-2.8.0 betas in november, but lost
> afterwards apparently)
> 
> autoheader contains (near the end)
> mv -f $tmpout ${config_h_in}
> 
> This is executed as e.g.
> mv -f autoh14321 config.in
> 
> The produced error line is:
> 
> E:/DJGPP/BIN/mv: cannot move `autoh14321' to `config.in':
> No such file or directory (ENOENT)
> 
> Looking at the internals of mv:
> The actual DOS call fails in _rename.c from libc 2.02alphaJan98 (not
> that that matters, since the 'mv' I originally used was the one from the
> latest fileutils (3.16)):
> 
> 
> The next step I took was going to sleep (I spent several hours to find
> what I have found so far), in the hope that a new day would bring me
> more wisdom. It did not... :-6 
> 

As I remember from previous posts this all was done under Windows 95.
Windows 95 has one rather annoying thing that is not in MS-DOS only
and as I know also under Windows NT:

   You cannot under Win95 delete or rename file if it is 
   opened by other process (one will get EACCESS in this situation).
   
I met this situation earlier in my own programs (forgot to close a file 
which I wanted to rename). As I looked in autoheader this temporary file 
is created by redirecting output of come command. Maybe bash did not close 
this file up to this time.

If so then a possible workaround (not very beauty) can be replacing
'mv' with 'cp' in autoheader

Andris Pavenis