Message-Id: <199803121754.TAA65036@ieva06.lanet.lv> From: "Andris Pavenis" To: Vik Heyndrickx 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 In-reply-to: <3507A327.28E2@rug.ac.be> Precedence: bulk > Date: Thu, 12 Mar 1998 09:56:07 +0100 > From: Vik Heyndrickx > 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