Mail Archives: djgpp/1998/03/12/12:53:13
> 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
- Raw text -