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