Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3507A327.28E2@rug.ac.be>
Date: Thu, 12 Mar 1998 09:56:07 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com, Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Subject: Re: Rebuilding config.in in gcc-2.8.1
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980311110023 DOT 7344C-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

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)):

    /* LFN rename */
    r.x.ax = 0x7156;
    /* Source name: 'autoh14321' */
    r.x.dx = __tb_offset;
    r.x.ds = __tb_segment;
    /* Destination name: '9$$djren$$.$$temp$$' (sic) */
    r.x.di = __tb_offset + olen;
    r.x.es = __tb_segment;
    /* At this point:
       no file with the name '9$$djren$$.$$temp$$' exists.
       A file with the name 'autoh14321' does exist.
       Its DOS attribute read/only is not SET.
       (and those three things are no speculation BTW) */
    _put_path2(tempfile, olen);
    _put_path(old);
    /* I know that these _put_path instructions DID work
       as they were supposed to, meaning that at the other
       end (the DOS side) of the INT21 call these names
       are seen correctly. It is no bug in _rename, but
       I start to wish it were! */
    __dpmi_int(0x21, &r);
    /* This call fails with error code 5 (_DOS_ERR_ACCESS)
       while it was supposed to succeed */
    /* I did not investigate further how the error code became
       ENOENT at the end, since I found that this __dpmi_int
       call was the real reason for the error message */

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 

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/