old bootstrap error emerges again
Bootstrap Emacs with MinGW under WindowsXP failed due to compiling lisp/usr/vc-dav.el requires file DOC must be present under directory etc/ And I find this problem has been reported before, and a patch has been proposed: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00388.html It seems nobody care about that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org > From: Zhang Wei <[EMAIL PROTECTED]> > Date: Sat, 18 Mar 2006 19:59:12 +0800 > > Eli Zaretskii <[EMAIL PROTECTED]> writes: > > > Are you using MSYS? > > yes, i'm using MinGW + MSYS. Then please show us the full transcript of a failed bootstrap. I need to see the exact error message, and any other messages leading to it, so that I could understand the problem. I don't have MSYS installed, so I cannot reproduce this problem on my machines. > If some GNU Emacs developers feel offended by the referencing > of an old report Not by referencing to an old report, by assuming we don't care for the problem. We do care, but we need help from the users who report them to figure out the exact reasons and the best way of fixing them. > I don't think it's anybody's fault if there's a subtle unsolved bug > in a program, because different people has a diverse different > system configuration. This isn't about assigning blame. This is about understanding the reasons for the problem in the specific setup you have on your system. We cannot solve a problem if we don't understand it. > May be I didn't describe the problem clearly. The problem is bootstrap > stoped while compliling lisp/url/vc-dav.el, it complains that there's > no DOC file in the etc/ directory, so I have to copy the `DOC' file > from lib-src/ to etc/ manually and bootstrap again. I understood your description. Still, I'm asking for the full transcript of the bootstrap, because there might be something else going on that you didn't see. On my machine (without MSYS) the bootstrap always succeeds. By comparing your transcript with mine, I might be able to understand what went wrong on your system. In case you don't know how to produce a transcript of the bootstrap, here's the commands to type: cd nt configure 2>&1 | tee transcript.txt make bootstrap 2>&1 | tee -a transcript.txt (You will need a port of the `tee' command.) Then post here the file transcript.txt created by these commands. Thanks in advance. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org > Date: Sat, 18 Mar 2006 09:22:56 -0700 > > I am seeing the "DOC" error too. > My setup: english Windows XP Pro, MinGW-3.1.0-1, cygwin tool set, no msys. > Logfile: > [...] > In toplevel form: > url/vc-dav.el:29:1:Error: Cannot open doc string file > "c:/Users/deyke/emacs-build/work/etc/DOC" > make[1]: *** [compile-SH] Error 1 > make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' > make: *** [bootstrap-gmake] Error 2 Thanks, this gives me something that I can work with. Here's the problem: Emacs shouldn't even look for the file named DOC, it should look for DOC-X. This is because loadup.el has this fragment: (if (memq system-type '(ms-dos windows-nt)) (setq name (expand-file-name (if (fboundp 'x-create-frame) "DOC-X" "DOC") "../etc")) (setq name (concat (expand-file-name "../etc/DOC-") name)) (if (file-exists-p name) (delete-file name)) (copy-file (expand-file-name "../etc/DOC") name t)) (Snarf-documentation (file-name-nondirectory name))) So, on Windows, since x-create-frame is bound, it calls Snarf-documentation with the argument "DOC-X". Snarf-documentation then records this name in the variable internal-doc-file-name, and that name is dumped in emacs.exe. So when byte-compiling for some reason calls for a doc file, Emacs should look for DOC-X. Can you see where the above breaks on your system? In particular, when does Vdoc_file_name (defined in doc.c) gets assigned the file name which ends with "DOC", not "DOC-X"? Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Dieter Deyke <[EMAIL PROTECTED]> writes: > In toplevel form: > url/url-handlers.el:243:1:Error: Cannot open doc string file > "c:/Users/deyke/emacs-build/work/etc/DOC" Strange, this is a blank line in the version I have, and that file has not changed since 2 January. The other lines that gave you this error were requiring other files from the url package. Do you have an older version of url in your site-lisp directory? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Jason Rumney <[EMAIL PROTECTED]> writes: > Dieter Deyke <[EMAIL PROTECTED]> writes: > >> In toplevel form: >> url/url-handlers.el:243:1:Error: Cannot open doc string file >> "c:/Users/deyke/emacs-build/work/etc/DOC" > > Strange, this is a blank line in the version I have, and that file has > not changed since 2 January. > > The other lines that gave you this error were requiring other files > from the url package. Do you have an older version of url in your > site-lisp directory? I don't think so, this was a clean cvs checkout from today. But you are right, in my copy there is a blank line too, right after the macro definition of url-handlers-create-wrapper. -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> Well, one way to try to debug this is to say "make bootstrap" again
> (without the workaround), let it fail, then run Emacs under GDB and
> let it byte-compile the offending file vc-dav.el with precisely the
> same command-line arguments as when Emacs is run from Make. But
> before you run Emacs, after starting GDB, set a breakpoint in doc.c,
> in the function get_doc_string, on the line which says:
>
> error ("Cannot open doc string file \"%s\"", name);
>
> (this is the line that displays the error message and aborts the
> compilation). When this breakpoint breaks, please post here the
> backtrace. Maybe that would give us some ideas.
>
> TIA
(gdb) set args -f batch-byte-compile url/vc-dav.el
(gdb) run
Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/emacs.exe -f batch
-byte-compile url/vc-dav.el
Breakpoint 1, get_doc_string (filepos=-2047792, unibyte=0, definition=0)
at doc.c:196
196 error ("Cannot open doc string file \"%s\"", name);
(gdb) backtrace
#0 get_doc_string (filepos=-2047792, unibyte=0, definition=0) at doc.c:196
#1 0x0110d925 in Fdocumentation (function=27789273, raw=27674673) at doc.c:456
#2 0x010205ed in Ffuncall (nargs=3, args=0x82d110) at eval.c:2904
#3 0x0111e063 in Fbyte_code (bytestr=34201523, vector=37091204, maxdepth=56)
at bytecode.c:694
#4 0x010209b7 in funcall_lambda (fun=35206436, nargs=1, arg_vector=0x82d244)
at eval.c:3088
#5 0x01020486 in Ffuncall (nargs=2, args=0x82d240) at eval.c:2956
#6 0x0111e063 in Fbyte_code (bytestr=34201331, vector=37121924, maxdepth=40)
at bytecode.c:694
#7 0x010209b7 in funcall_lambda (fun=35207524, nargs=2, arg_vector=0x82d374)
at eval.c:3088
#8 0x01020486 in Ffuncall (nargs=3, args=0x82d370) at eval.c:2956
#9 0x0111e063 in Fbyte_code (bytestr=34559971, vector=37071364, maxdepth=88)
at bytecode.c:694
#10 0x010209b7 in funcall_lambda (fun=35459812, nargs=1, arg_vector=0x82d4bc)
at eval.c:3088
#11 0x01020486 in Ffuncall (nargs=2, args=0x82d4b8) at eval.c:2956
#12 0x0111e063 in Fbyte_code (bytestr=29906179, vector=37089924, maxdepth=56)
at bytecode.c:694
#13 0x010209b7 in funcall_lambda (fun=35503940, nargs=2, arg_vector=0x82d5e4)
at eval.c:3088
#14 0x01020486 in Ffuncall (nargs=3, args=0x82d5e0) at eval.c:2956
---Type to continue, or q to quit---
#15 0x0111e063 in Fbyte_code (bytestr=29906307, vector=37120388, maxdepth=32)
at bytecode.c:694
#16 0x010209b7 in funcall_lambda (fun=35503620, nargs=2, arg_vector=0x82d704)
at eval.c:3088
#17 0x01020486 in Ffuncall (nargs=3, args=0x82d700) at eval.c:2956
#18 0x0111e063 in Fbyte_code (bytestr=35731251, vector=37092740, maxdepth=40)
at bytecode.c:694
#19 0x0101f8b1 in Feval (form=35136365) at eval.c:2247
#20 0x0106f3d3 in readevalloop (readcharfun=27760665, stream=0x77c5fd00,
sourcename=35723635, evalfun=0x101f4e0 , printflag=0,
unibyte=27674625, readfun=27674625, start=27674625, end=27674625)
at lread.c:1480
#21 0x0106e27a in Fload (file=34166371, noerror=27674625, nomessage=27674673,
nosuffix=27674625, must_suffix=27674673) at lread.c:960
#22 0x01080d7c in Frequire (feature=34540833, filename=27674625,
noerror=27674625) at fns.c:3619
#23 0x0102060b in Ffuncall (nargs=2, args=0x82dae0) at eval.c:2907
#24 0x0111e063 in Fbyte_code (bytestr=34742067, vector=35697668, maxdepth=40)
at bytecode.c:694
#25 0x0101f8b1 in Feval (form=35495149) at eval.c:2247
#26 0x0106f3d3 in readevalloop (readcharfun=27760665, stream=0x77c5fce0,
sourcename=29918323, evalfun=0x101f4e0 , printflag=0,
unibyte=27674625, readfun=27674625, start=27674625, end=27674625)
---Type to continue, or q to quit---
at lread.c:1480
#27 0x0106e27a in Fload (file=29918515, noerror=27674625, nomessage=27674625,
nosuffix=27674625, must_suffix=27674625) at lread.c:960
#28 0x0101f910 in Feval (form=28313573) at eval.c:2255
#29 0x0101cde1 in Fprogn (args=28313981) at eval.c:432
#30 0x010209ea in funcall_lambda (fun=28313549, nargs=1, arg_vector=0x82df0c)
at eval.c:3081
#31 0x01020851 in apply_lambda (fun=28313549, args=35498133, eval_flag=1)
at eval.c:3010
#32 0x0101f6be in Feval (form=35498141) at eval.c:2299
#33 0x0106f3d3 in readevalloop (readcharfun=35179524, stream=0x0,
sourcename=29907459, evalfun=0x101f4e0 , printflag=0,
unibyte=27674625, readfun=27674625, start=27674625, end=27674625)
at lread.c:1480
#34 0x0106f725 in Feval_buffer (buffer=35179524, printflag=27674625,
filename=29907459, unibyte=27674625, do_allow_print=27674673)
at lread.c:1543
#35 0x0101f910 in Feval (form=28251109) at eval.c:2255
#36 0x0101cde1 in Fprogn (args=28251101) at eval.c:432
#37 0x0101dd18 in Flet (args=28250805) at eval.c:1053
#38 0x0101faa0 in Feval (form=28250725) at eval.c:2188
#39 0x0101e277 in Funwind_protect (args=28281941) at eval.c:1316
#40 0x0101faa0 in Feval (form=28250717) at eval.c:2188
---Type to continue, or q to quit---
#41 0x0101cde1 in Fprogn (ar
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
> Date: Sat, 18 Mar 2006 17:59:08 -0700
>
> (gdb) set args -f batch-byte-compile url/vc-dav.el
> (gdb) run
> Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/emacs.exe -f
> batch
> -byte-compile url/vc-dav.el
>
> Breakpoint 1, get_doc_string (filepos=-2047792, unibyte=0, definition=0)
> at doc.c:196
> 196 error ("Cannot open doc string file \"%s\"", name);
> (gdb) backtrace
> #0 get_doc_string (filepos=-2047792, unibyte=0, definition=0) at doc.c:196
> #1 0x0110d925 in Fdocumentation (function=27789273, raw=27674673) at
> doc.c:456
Thanks. At this point, it would help if you do the following:
. Print the value of filepos:
(gdb) p filepos
(gdb) pr
. Print the value of Vdoc_file_name, which should be a string:
(gdb) p Vdoc_file_name
(gdb) pr
. Print the value of Vdoc_directory, which should also be a string:
(gdb) p Vdoc_directory
(gdb) pr
. Produce a Lisp backtrace:
(gdb) xbacktrace
. Post here the results.
Thanks!
Note that, for these commands to work, you need either to start GDB in
the src directory or type "source /path-to-src/src/.gdbinit" inside
GDB, because the commands `pr' and `xbacktrace' are defined there.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org > Date: Sun, 19 Mar 2006 07:44:28 -0700 > > (gdb) xbacktrace > "ad-real-documentation" > "ad-subr-arglist" > "ad-arglist" > "ad-make-advised-definition" > "ad-activate-advised-definition" > "ad-activate" Thanks. These "ad-*" functions in the Lisp backtrace look strange: they seem to indicate that defadvice is used somewhere, but I cannot see any such defadvice's in the lisp/url directory. Can you look around and try to find where are those defadvice's? > "byte-code" > "require" > "byte-code" > "load" > "load-library" Also, it would be good to know what package is being loaded in the last line above, which says "load-library", and what feature is being required in the "require" line before that. Can you try to find out? The way to do that is identify the frames in the C backtrace that correspond to these lines in the Lisp backtrace. For example, the innermost call to Frequire would probably correspond to the "require" line. Then print the first argument (with `pr') and see what it is. For load-library, the "load" (Fload in C) line that preceeds it will tell you via its 1st arg what file is being loaded. Perhaps this information will show where do those ad-* things come from. Thanks again for working on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: Dieter Deyke <[EMAIL PROTECTED]> >> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org >> Date: Sun, 19 Mar 2006 07:44:28 -0700 >> >> (gdb) xbacktrace >> "ad-real-documentation" >> "ad-subr-arglist" >> "ad-arglist" >> "ad-make-advised-definition" >> "ad-activate-advised-definition" >> "ad-activate" > > Thanks. These "ad-*" functions in the Lisp backtrace look strange: > they seem to indicate that defadvice is used somewhere, but I cannot > see any such defadvice's in the lisp/url directory. Can you look > around and try to find where are those defadvice's? > >> "byte-code" >> "require" >> "byte-code" >> "load" >> "load-library" > > Also, it would be good to know what package is being loaded in the > last line above, which says "load-library", and what feature is being > required in the "require" line before that. Can you try to find out? > The way to do that is identify the frames in the C backtrace that > correspond to these lines in the Lisp backtrace. For example, the > innermost call to Frequire would probably correspond to the "require" > line. Then print the first argument (with `pr') and see what it is. > For load-library, the "load" (Fload in C) line that preceeds it will > tell you via its 1st arg what file is being loaded. > > Perhaps this information will show where do those ad-* things come > from. > > Thanks again for working on this. The lowest Fload I found had a first arg of "uniquify", I do not know how to decode the args of the Frequire calling it. feature showed up as 0, and filename as nil. The next Fload higher up had an first arg of "emacsrc". Makes me think, does bootstrapping emacs read the ~/.emacsrc file I have? May be we can speed up debugging by hooking up via IM or IRC, and you provide me with lines I paste into the debugger, and I will paste back results. -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Sorry Eli, my last backtrace was useless, I did not put the necessary -batch --no-init-file --no-site-file --multibyte arguments on the command line when calling emacs. I am really new at this. Anyway, this time I did it better, and here are the new results: (gdb) backtrace #0 get_doc_string (filepos=-2579664, unibyte=0, definition=0) at doc.c:196 #1 0x0110d925 in Fdocumentation (function=27819993, raw=27674673) at doc.c:456 #2 0x0101f88c in Feval (form=35711621) at eval.c:2244 #3 0x0101cc44 in For (args=35711541) at eval.c:328 #4 0x0101faa0 in Feval (form=35711637) at eval.c:2188 #5 0x0101fa50 in Feval (form=35711701) at eval.c:2206 #6 0x0101fa50 in Feval (form=35705733) at eval.c:2206 #7 0x0101f72b in Feval (form=35710653) at eval.c:2297 #8 0x0101cde1 in Fprogn (args=35710637) at eval.c:432 #9 0x010209ea in funcall_lambda (fun=35710605, nargs=2, arg_vector=0x82c8a0) at eval.c:3081 #10 0x01020486 in Ffuncall (nargs=3, args=0x82c89c) at eval.c:2956 #11 0x0101fc0b in Fapply (nargs=2, args=0x82c918) at eval.c:2393 #12 0x01020117 in apply1 (fn=35710605, arg=35710525) at eval.c:2654 #13 0x0101f723 in Feval (form=35710541) at eval.c:2297 #14 0x0106f3d3 in readevalloop (readcharfun=31538180, stream=0x0, sourcename=35482179, evalfun=0x101f4e0 , printflag=0, unibyte=27674625, readfun=27674625, start=27674625, end=27674625) at lread.c:1480 #15 0x0106f725 in Feval_buffer (buffer=31538180, printflag=27674625, filename=35482179, unibyte=27674625, do_allow_print=27674673) at lread.c:1543 #16 0x0101f910 in Feval (form=28251109) at eval.c:2255 ---Type to continue, or q to quit--- #17 0x0101cde1 in Fprogn (args=28251101) at eval.c:432 #18 0x0101dd18 in Flet (args=28250805) at eval.c:1053 #19 0x0101faa0 in Feval (form=28250725) at eval.c:2188 #20 0x0101e277 in Funwind_protect (args=28281941) at eval.c:1316 #21 0x0101faa0 in Feval (form=28250717) at eval.c:2188 #22 0x0101cde1 in Fprogn (args=28250653) at eval.c:432 #23 0x0101db11 in FletX (args=28250541) at eval.c:995 #24 0x0101faa0 in Feval (form=28250301) at eval.c:2188 #25 0x0101cde1 in Fprogn (args=28282325) at eval.c:432 #26 0x0101cd1b in Fif (args=28250181) at eval.c:381 #27 0x0101faa0 in Feval (form=28250141) at eval.c:2188 #28 0x0101cde1 in Fprogn (args=28250133) at eval.c:432 #29 0x010209ea in funcall_lambda (fun=28282341, nargs=4, arg_vector=0x82d1a4) at eval.c:3081 #30 0x01020486 in Ffuncall (nargs=5, args=0x82d1a0) at eval.c:2956 #31 0x0102024e in call4 (fn=27790625, arg1=35482179, arg2=36208307, arg3=27674625, arg4=27674673) at eval.c:2755 #32 0x0106e5f5 in Fload (file=36208307, noerror=27674625, nomessage=27674673, nosuffix=27674625, must_suffix=27674673) at lread.c:914 #33 0x01080d7c in Frequire (feature=37716329, filename=27674625, noerror=27674625) at fns.c:3619 #34 0x0101f8b1 in Feval (form=29348213) at eval.c:2247 #35 0x0106f3d3 in readevalloop (readcharfun=34987012, stream=0x0, ---Type to continue, or q to quit--- sourcename=34796499, evalfun=0x101f4e0 , printflag=0, unibyte=27674625, readfun=27674625, start=27674625, end=27674625) at lread.c:1480 #36 0x0106f725 in Feval_buffer (buffer=34987012, printflag=27674625, filename=34796499, unibyte=27674625, do_allow_print=27674673) at lread.c:1543 #37 0x0101f910 in Feval (form=28251109) at eval.c:2255 #38 0x0101cde1 in Fprogn (args=28251101) at eval.c:432 #39 0x0101dd18 in Flet (args=28250805) at eval.c:1053 #40 0x0101faa0 in Feval (form=28250725) at eval.c:2188 #41 0x0101e277 in Funwind_protect (args=28281941) at eval.c:1316 #42 0x0101faa0 in Feval (form=28250717) at eval.c:2188 #43 0x0101cde1 in Fprogn (args=28250653) at eval.c:432 #44 0x0101db11 in FletX (args=28250541) at eval.c:995 #45 0x0101faa0 in Feval (form=28250301) at eval.c:2188 #46 0x0101cde1 in Fprogn (args=28282325) at eval.c:432 #47 0x0101cd1b in Fif (args=28250181) at eval.c:381 #48 0x0101faa0 in Feval (form=28250141) at eval.c:2188 #49 0x0101cde1 in Fprogn (args=28250133) at eval.c:432 #50 0x010209ea in funcall_lambda (fun=28282341, nargs=4, arg_vector=0x82dbc4) at eval.c:3081 #51 0x01020486 in Ffuncall (nargs=5, args=0x82dbc0) at eval.c:2956 #52 0x0102024e in call4 (fn=27790625, arg1=34796499, arg2=34795907, ---Type to continue, or q to quit--- arg3=27674625, arg4=27674673) at eval.c:2755 #53 0x0106e5f5 in Fload (file=34795907, noerror=27674625, nomessage=27674673, nosuffix=27674625, must_suffix=27674673) at lread.c:914 #54 0x01080d7c in Frequire (feature=34707009, filename=27674625, noerror=27674625) at fns.c:3619 #55 0x0102060b in Ffuncall (nargs=2, args=0x82dee4) at eval.c:2907 #56 0x0101fc0b in Fapply (nargs=2, args=0x82dee4) at eval.c:2393 #57 0x0102076e in Ffuncall (nargs=3, args=0x82dee0) at eval.c:2882 #58 0x0111e063 in Fbyte_code (bytestr=34069715, vector=36134532, maxdepth=32) at bytecode.c:694 #59 0x010209b7 in funcall_lambda (fun=36128580, nargs=1, arg_vector=0x82e004) at eval.c:3088 #60 0x01020486 in Ffuncall (nargs=2, args=0x82e
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Are you using MSYS? yes, i'm using MinGW + MSYS. > Would you please stop offending the few volunteers who maintain the > Windows port? Even if you believe the problem is still unsolved, > that's not a reason good enough to say that ``nobody cares'' about it. Sorry, if you feel offended. I just happen to bump into a problem and searched the web and found the same problem has been reproted before. If some GNU Emacs developers feel offended by the referencing of an old report, I could just describe the problem next time, no more any referencing. But that is a quite strange request, I don't think it's anybody's fault if there's a subtle unsolved bug in a program, because different people has a diverse different system configuration. I'm not a native english speaker, I have to reference the dictionary many times while composing email in english, It's quite an opportunity I pick up a wrong word to express my thought. If some people feel offended, sorry for that. And finally, thanks for your correction of the grammer. > The facts are utterly different from your assertion: out of the 3 > problems reported in that message, 2 are already resolved (albeit in a > way that is different from what was suggested there). As for the 3rd, > the one with the absent DOC file, I asked at some point to provide > details about it, but got no responses. If you can afford investing > some effort in working with us on this problem, I'm sure we will > resolve it in no time. May be I didn't describe the problem clearly. The problem is bootstrap stoped while compliling lisp/url/vc-dav.el, it complains that there's no DOC file in the etc/ directory, so I have to copy the `DOC' file from lib-src/ to etc/ manually and bootstrap again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> Date: Sat, 18 Mar 2006 00:35:36 +0800 > From: "Zhang Wei" <[EMAIL PROTECTED]> > Cc: > > Bootstrap Emacs with MinGW under WindowsXP failed due to compiling > lisp/usr/vc-dav.el requires file DOC must be present under directory etc/ Are you using MSYS? > And I find this problem has been reported before, and a patch has been > proposed: > > http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00388.html > > It seems nobody care about that. Would you please stop offending the few volunteers who maintain the Windows port? Even if you believe the problem is still unsolved, that's not a reason good enough to say that ``nobody cares'' about it. The facts are utterly different from your assertion: out of the 3 problems reported in that message, 2 are already resolved (albeit in a way that is different from what was suggested there). As for the 3rd, the one with the absent DOC file, I asked at some point to provide details about it, but got no responses. If you can afford investing some effort in working with us on this problem, I'm sure we will resolve it in no time. So please consider providing a complete transcript of the bootstrap process in your environment, up to and including the portion where it fails due to the missing DOC file. I don't have MSYS installed, and in my environment the bootstrap succeeds every time. So I need to see the details of your build to understand what goes wrong and why. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: Dieter Deyke <[EMAIL PROTECTED]> >> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org >> Date: Sat, 18 Mar 2006 09:22:56 -0700 >> >> I am seeing the "DOC" error too. >> My setup: english Windows XP Pro, MinGW-3.1.0-1, cygwin tool set, no msys. >> Logfile: >> [...] >> In toplevel form: >> url/vc-dav.el:29:1:Error: Cannot open doc string file >> "c:/Users/deyke/emacs-build/work/etc/DOC" >> make[1]: *** [compile-SH] Error 1 >> make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' >> make: *** [bootstrap-gmake] Error 2 > > Thanks, this gives me something that I can work with. > > Here's the problem: Emacs shouldn't even look for the file named DOC, > it should look for DOC-X. This is because loadup.el has this > fragment: > > (if (memq system-type '(ms-dos windows-nt)) > (setq name (expand-file-name > (if (fboundp 'x-create-frame) "DOC-X" "DOC") "../etc")) > (setq name (concat (expand-file-name "../etc/DOC-") name)) > (if (file-exists-p name) > (delete-file name)) > (copy-file (expand-file-name "../etc/DOC") name t)) > (Snarf-documentation (file-name-nondirectory name))) > > So, on Windows, since x-create-frame is bound, it calls > Snarf-documentation with the argument "DOC-X". Snarf-documentation > then records this name in the variable internal-doc-file-name, and > that name is dumped in emacs.exe. So when byte-compiling for some > reason calls for a doc file, Emacs should look for DOC-X. > > Can you see where the above breaks on your system? In particular, > when does Vdoc_file_name (defined in doc.c) gets assigned the file > name which ends with "DOC", not "DOC-X"? > > Thanks. I'm not sure on how to debug this. Let me start to point out that there were 3 errors about missing DOC, but the first 2 were not fatal: ... In toplevel form: url/url-dav.el:36:1:Error: Cannot open doc string file "c:/Users/deyke/emacs-build/work/etc/DOC" Compiling url/url-dired.el Wrote c:/Users/deyke/emacs-build/work/lisp/url/url-dired.elc Compiling url/url-expand.el Wrote c:/Users/deyke/emacs-build/work/lisp/url/url-expand.elc Compiling url/url-file.el ... In toplevel form: url/url-handlers.el:243:1:Error: Cannot open doc string file "c:/Users/deyke/emacs-build/work/etc/DOC" Compiling url/url-history.el Wrote c:/Users/deyke/emacs-build/work/lisp/url/url-history.elc Compiling url/url-http.el ... In toplevel form: url/vc-dav.el:29:1:Error: Cannot open doc string file "c:/Users/deyke/emacs-build/work/etc/DOC" make[1]: *** [compile-SH] Error 1 make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' make: *** [bootstrap-gmake] Error 2 Second, after that build stopped, a find | grep DOC came up empty, so if anything would expect to find DOC-X, there was none to be found. Next I probed loadup.el: system-type --> windows-nt (fboundp 'x-create-frame) --> t (setq name (expand-file-name (if (fboundp 'x-create-frame) "DOC-X" "DOC") "../etc")) --> "c:/Users/deyke/emacs-build/etc/DOC-X" Finally, this is my current work-aound, which seems to give me a working emacs, although I do not know if the DOC strings are all OK: cd work/nt call configure.bat --with-gcc --no-debug --no-cygwin --cflags -IC:/Users/deyke/emacs-build/include --prefix C:/emacs make bootstrap REM The last command will have failed with errors, finish the job cd /d "%basedir%\work\lib-src" make DOC copy DOC ..\etc\DOC cd /d "%basedir%\work\nt" make cd /d "%basedir%\work\lisp" make recompile EMACS=../src/oo-spd/i386/emacs cd /d "%basedir%\work\nt" make info So, could you please guide me in what I have to do to debug this? Thanks, -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
> Date: Sat, 18 Mar 2006 12:55:35 -0700
>
> I'm not sure on how to debug this. Let me start to point out that
> there were 3 errors about missing DOC
Yes, I've seen those as well in your transcript. Needless to say, in
my builds none of them are present.
> but the first 2 were not fatal:
No, they are all fatal. It's just that the shell's for loop invoked
by Make doesn't stop until it finishes (you will see that
url/vc-dav.el is the last Lisp file that is compiled), so Make only
sees the non-zero exit status when the list of files to compile is
exhausted and the subsidiary shell exits.
> Second, after that build stopped, a find | grep DOC came up empty, so
> if anything would expect to find DOC-X, there was none to be found.
In my builds, I don't have DOC-X either, at this stage of the build.
But the problems still don't happen for me. I think Emacs shouldn't
look for the doc string file at all at this place. The DOC vs DOC-X
thing was just another strange thing, so I mentioned it.
> So, could you please guide me in what I have to do to debug this?
Well, one way to try to debug this is to say "make bootstrap" again
(without the workaround), let it fail, then run Emacs under GDB and
let it byte-compile the offending file vc-dav.el with precisely the
same command-line arguments as when Emacs is run from Make. But
before you run Emacs, after starting GDB, set a breakpoint in doc.c,
in the function get_doc_string, on the line which says:
error ("Cannot open doc string file \"%s\"", name);
(this is the line that displays the error message and aborts the
compilation). When this breakpoint breaks, please post here the
backtrace. Maybe that would give us some ideas.
TIA
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> Thanks. At this point, it would help if you do the following:
>
> . Print the value of filepos:
>
> (gdb) p filepos
> (gdb) pr
>
> . Print the value of Vdoc_file_name, which should be a string:
>
> (gdb) p Vdoc_file_name
> (gdb) pr
>
> . Print the value of Vdoc_directory, which should also be a string:
>
> (gdb) p Vdoc_directory
> (gdb) pr
>
> . Produce a Lisp backtrace:
>
> (gdb) xbacktrace
>
> . Post here the results.
(gdb) break 196
Breakpoint 1 at 0x110d68c: file doc.c, line 196.
(gdb) run
Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/emacs.exe -f batch
-byte-compile url/vc-dav.el
Breakpoint 1, get_doc_string (filepos=-2047792, unibyte=0, definition=0)
at doc.c:196
196 error ("Cannot open doc string file \"%s\"", name);
(gdb) source ../src/.gdbinit
Environment variable "DISPLAY" not defined.
Environment variable "TERM" not defined.
Breakpoint 2 at 0x1152a76: file w32fns.c, line 8965.
Breakpoint 3 at 0x109f0e6: file sysdep.c, line 1395.
(gdb) p filepos
$1 = -2047792
(gdb) pr
warning: -
warning: 2
warning: 5
warning: 5
warning: 9
warning: 7
warning: 4
(gdb) p Vdoc_file_name
$2 = 35481283
(gdb) pr
warning: "
warning: D
warning: O
warning: C
warning: "
(gdb) p Vdoc_directory
$3 = 35480707
(gdb) pr
warning: "
warning: c
warning: :
warning: /
warning: U
warning: s
warning: e
warning: r
warning: s
warning: /
warning: d
warning: e
warning: y
warning: k
warning: e
warning: /
warning: e
warning: m
warning: a
warning: c
warning: s
warning: -
warning: b
warning: u
warning: i
warning: l
warning: d
warning: /
warning: w
warning: o
warning: r
warning: k
warning: /
warning: e
warning: t
warning: c
warning: /
warning: "
(gdb) xbacktrace
"ad-real-documentation"
"ad-subr-arglist"
"ad-arglist"
"ad-make-advised-definition"
"ad-activate-advised-definition"
"ad-activate"
"byte-code"
"require"
"byte-code"
"load"
"load-library"
"eval-buffer"
"let"
"unwind-protect"
"let*"
"if"
"load-with-code-conversion"
"load"
"let"
"if"
0x210aa65 Lisp type 5
"funcall"
"progn"
---Type to continue, or q to quit---
"condition-case"
"if"
"let"
"let"
"let"
"command-line"
"unwind-protect"
"let"
"if"
"normal-top-level"
(gdb)
--
Dieter Deyke
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org > Date: Sun, 19 Mar 2006 14:19:18 -0700 Sorry for the long delay: I don't have enough time to work on non-trivial problems during weekdays. > Sorry Eli, my last backtrace was useless, I did not put the necessary > -batch --no-init-file --no-site-file --multibyte arguments on the > command line when calling emacs. I am really new at this. Anyway, this > time I did it better, and here are the new results: > > (gdb) backtrace > #0 get_doc_string (filepos=-2579664, unibyte=0, definition=0) at doc.c:196 > #1 0x0110d925 in Fdocumentation (function=27819993, raw=27674673) at > doc.c:456 Okay, thanks. What I need to see now is the value of the argument `function' passed to Fdocumentation above. The following commands will do this: (gdb) up 1 (gdb) pr function (gdb) xtype (The first of these commands goes up to the frame of Fdocumentation.) Then use the appropriate x* command (e.g., xsymbol for symbols etc.), according to what xtype prints, to show the value of function. Please note that, to reproduce what happens during bootstrap, you need: . Invoke the temporary binary of emacs.exe used by the bootstrap process, not the one produced by a successful build. This intermediary binary can be found during bootstrap in the bin subdirectory, but it is deleted afterwards. So you will need to copy it while the bootstrap runs, and that is the binary you should run under GDB. . Make sure there's no url-handlers.elc when you run Emacs to compile vc-dav.el or url-dav.el. . Make sure there's no DOC or DOC-X in the etc subdirectory. Also, please tell me what is the value of system-type in the MSYS build. TIA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> Okay, thanks. What I need to see now is the value of the argument
> `function' passed to Fdocumentation above. The following commands
> will do this:
>
>(gdb) up 1
>(gdb) pr function
>(gdb) xtype
>
> (The first of these commands goes up to the frame of Fdocumentation.)
> Then use the appropriate x* command (e.g., xsymbol for symbols etc.),
> according to what xtype prints, to show the value of function.
>
> Please note that, to reproduce what happens during bootstrap, you
> need:
>
> . Invoke the temporary binary of emacs.exe used by the bootstrap
> process, not the one produced by a successful build. This
> intermediary binary can be found during bootstrap in the bin
> subdirectory, but it is deleted afterwards. So you will need to
> copy it while the bootstrap runs, and that is the binary you
> should run under GDB.
>
> . Make sure there's no url-handlers.elc when you run Emacs to
> compile vc-dav.el or url-dav.el.
>
> . Make sure there's no DOC or DOC-X in the etc subdirectory.
>
> Also, please tell me what is the value of system-type in the MSYS
> build.
>
> TIA
The strange thing is that the error vanished yesterday on my work PC,
but using the same tools I still get it on my home PC:
Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/my-emacs.exe -batc
h --no-init-file --no-site-file --multibyte -f batch-byte-compile url/vc-dav.el
Breakpoint 3, get_doc_string (filepos=-2581128, unibyte=0, definition=0)
at doc.c:196
196 error ("Cannot open doc string file \"%s\"", name);
(gdb) up 1
#1 0x0110da05 in Fdocumentation (function=27819993, raw=27674673) at doc.c:456
456 tem = get_doc_string (doc, 0, 0);
(gdb) print function
$1 = 27819993
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x1a87fd8
"file-exists-p"
(gdb)
As for your last question, I'm not using MSYS. My setup includes:
english XP Pro SP2
current cygwin
MinGW-3.1.0-1 in PATH before cygwin
If I start the emacs which was built during bootstrap it reports:
system-type
windows-nt
emacs-version
"22.0.50"
--
Dieter Deyke
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
> Date: Sat, 25 Mar 2006 08:54:45 -0700
>
> The strange thing is that the error vanished yesterday on my work PC,
> but using the same tools I still get it on my home PC:
Do you have the same sources (i.e. the same CVS check-out) on both of
these machines?
> Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/my-emacs.exe
> -batc
> h --no-init-file --no-site-file --multibyte -f batch-byte-compile
> url/vc-dav.el
>
> Breakpoint 3, get_doc_string (filepos=-2581128, unibyte=0, definition=0)
> at doc.c:196
> 196 error ("Cannot open doc string file \"%s\"", name);
> (gdb) up 1
> #1 0x0110da05 in Fdocumentation (function=27819993, raw=27674673) at
> doc.c:456
> 456 tem = get_doc_string (doc, 0, 0);
> (gdb) print function
> $1 = 27819993
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0x1a87fd8
> "file-exists-p"
> (gdb)
Thanks. Now please repeat this again, and this time put a breakpoint
in Fdocumentation; when it breaks, verify that the first argument is
indeed file-exists-p, and then step through the code until it calls
get_doc_string and tell me what you saw. When I do that on my system,
what I see is below. As you see, Fdocumentation returns nil without
ever calling get_doc_string. Can you find out what is different on
your machine, and why?
> As for your last question, I'm not using MSYS. My setup includes:
>
> english XP Pro SP2
> current cygwin
> MinGW-3.1.0-1 in PATH before cygwin
Okay, so perhaps Cygwin has something to do with this. Hopefully, we
will understand that when we find the reason for the different
behavior.
Here's a transcript of the GDB session on my machine:
D:\gnu\test\emacs\lisp>gdb ../bin/bootstrap-emacs.exe
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) br Fdocumentation
Breakpoint 1 at 0x10fc4e0: file doc.c, line 378.
(gdb) source ../src/.gdbinit
Environment variable "DISPLAY" not defined.
Environment variable "TERM" not defined.
Breakpoint 2 at 0x1133856: file w32fns.c, line 8965.
Breakpoint 3 at 0x109513b: file sysdep.c, line 1395.
(gdb) del 2 3
(gdb) r -batch --no-init-file --no-site-file --multibyte -l loaddefs.el -f batc
h-byte-compile url/vc-dav.el
Starting program: D:\gnu\test\emacs\lisp/../bin/bootstrap-emacs.exe -batch --no
-init-file --no-site-file --multibyte -l loaddefs.el -f batch-byte-compile url/v
c-dav.el
Loading subst-ksc...
Loading subst-gb2312...
Loading subst-big5...
Loading subst-jis...
Breakpoint 1, Fdocumentation (function=44196825, raw=44054577) at doc.c:378
378 int try_reload = 1;
(gdb) p function
$1 = 44196825
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x2a263d8
"file-exists-p"
(gdb) n
374 {
(gdb) n
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
389 fun = Findirect_function (function, Qnil);
(gdb)
390 if (SUBRP (fun))
(gdb)
392 if (XSUBR (fun)->doc == 0)
(gdb)
409 return Qnil;
(gdb)
477 }
(gdb)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org, > emacs-devel@gnu.org > From: Jason Rumney <[EMAIL PROTECTED]> > Date: Sat, 25 Mar 2006 19:58:14 + > > Dieter Deyke <[EMAIL PROTECTED]> writes: > > > 390 if (SUBRP (fun)) > > (gdb) > > 392 if (XSUBR (fun)->doc == 0) > > (gdb) > > 394 else if ((EMACS_INT) XSUBR (fun)->doc >= 0) > > Could it be that we are not explicitly setting doc to 0, and Dieter's > compiler is initializing its memory with something other than 0 to > detect this type of bug? Well, I think we both are using the same compiler, modulo the version. Dieter, what does your compiler say when invoked with --version, and what version of the MinGW runtime do you have installed? Also, did any of these change lately on the machine where the problem disappeared? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Well, I think we both are using the same compiler, modulo the version. > Dieter, what does your compiler say when invoked with --version, and > what version of the MinGW runtime do you have installed? Also, did > any of these change lately on the machine where the problem > disappeared? Just to see if the error was caused by my old MinGW-3.1.0-1 installation, I upgraded today to the latest released packages. Now I'm using the following packages from mingw: binutils-2.15.91-20040904-1.tar.gz gcc-core-3.4.2-20040916-1.tar.gz gdb-5.2.1-1.exe mingw-runtime-3.9.tar.gz mingw-utils-0.3.tar.gz mingw32-make-3.80.0-3.tar.gz w32api-3.6.tar.gz and these packages from gnuwin32: coreutils-5.3.0-bin.zip coreutils-5.3.0-dep.zip coreutils-5.3.0-doc.zip coreutils-5.3.0-src.zip findutils-4.2.20-2-bin.zip findutils-4.2.20-2-dep.zip findutils-4.2.20-2-doc.zip findutils-4.2.20-2-src.zip giflib-4.1.4-bin.zip giflib-4.1.4-dep.zip giflib-4.1.4-doc.zip giflib-4.1.4-lib.zip giflib-4.1.4-src.zip jpeg-6b-4-bin.zip jpeg-6b-4-dep.zip jpeg-6b-4-doc.zip jpeg-6b-4-lib.zip jpeg-6b-4-src.zip libpng-1.2.8-bin.zip libpng-1.2.8-dep.zip libpng-1.2.8-doc.zip libpng-1.2.8-lib.zip libpng-1.2.8-src.zip texinfo-4.8-bin.zip texinfo-4.8-dep.zip texinfo-4.8-doc.zip texinfo-4.8-src.zip tiff-3.8.2-bin.zip tiff-3.8.2-dep.zip tiff-3.8.2-doc.zip tiff-3.8.2-lib.zip tiff-3.8.2-src.zip xpm-3.5.1-1-bin.zip xpm-3.5.1-1-doc.zip xpm-3.5.1-1-lib.zip xpm-3.5.1-1-src.zip zlib-1.2.3-bin.zip zlib-1.2.3-doc.zip zlib-1.2.3-lib.zip zlib-1.2.3-src.zip All those changes did not affect the error: In toplevel form: url/vc-dav.el:29:1:Error: Cannot open doc string file "c:/Users/deyke/emacs-build/work/etc/DOC" make[1]: *** [compile-SH] Error 1 make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' make: *** [bootstrap-gmake] Error 2 -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
> From: Dieter Deyke <[EMAIL PROTECTED]> > Cc: Jason Rumney <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org, >emacs-devel@gnu.org > Date: Sun, 26 Mar 2006 09:52:33 -0700 > > All those changes did not affect the error: > > In toplevel form: > url/vc-dav.el:29:1:Error: Cannot open doc string file > "c:/Users/deyke/emacs-build/work/etc/DOC" > make[1]: *** [compile-SH] Error 1 > make[1]: Leaving directory `C:/Users/deyke/emacs-build/work/lisp' > make: *** [bootstrap-gmake] Error 2 Okay, thanks. I didn't expect the upgrade to change anything. We need to understand why XSUBR (fun)->doc is zero for me, but not for you. Hmm... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org, >> emacs-devel@gnu.org >> From: Jason Rumney <[EMAIL PROTECTED]> >> Date: Sat, 25 Mar 2006 19:58:14 + >> >> Dieter Deyke <[EMAIL PROTECTED]> writes: >> >> > 390 if (SUBRP (fun)) >> > (gdb) >> > 392 if (XSUBR (fun)->doc == 0) >> > (gdb) >> > 394 else if ((EMACS_INT) XSUBR (fun)->doc >= 0) >> >> Could it be that we are not explicitly setting doc to 0, and Dieter's >> compiler is initializing its memory with something other than 0 to >> detect this type of bug? > > Well, I think we both are using the same compiler, modulo the version. > Dieter, what does your compiler say when invoked with --version, and > what version of the MinGW runtime do you have installed? Also, did > any of these change lately on the machine where the problem > disappeared? [EMAIL PROTECTED] bin]$ ./gcc --version gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. MinGW version 3.1.0 contains the following list of packages: GCC-3.2.3-20030504-1.tar.gz binutils-2.13.90-20030111-1 mingw-runtime-3.1 w32api-2.4 gdb-5.2.1-1 mingw32-make-3.80.0-3 mingw-utils-0.2.tar.gz There is no difference between the 2 PCs (working and non-working) that I am aware of, and the tools did not change for a few weeks. But when I said I only have MinGW and cygwin, I oversimplified. The reality is that I have the following stuff in the path (in that order): MinGW is first the combined bin directory resulting from installing the following packages from the gnuwin32 site is second: GnuWin32 Packages.URL giflib-4.1.4-bin.zip libpng-1.2.8-dep.zip tiff-3.8.2-doc.zip MinGW - Download.URLgiflib-4.1.4-dep.zip libpng-1.2.8-doc.zip tiff-3.8.2-lib.zip MinGW-3.1.0-1.exe giflib-4.1.4-doc.zip libpng-1.2.8-lib.zip tiff-3.8.2-src.zip coreutils-5.3.0-bin.zip giflib-4.1.4-lib.zip libpng-1.2.8-src.zip xpm-3.5.1-1-bin.zip coreutils-5.3.0-dep.zip giflib-4.1.4-src.zip mingw32-make-3.80.0-3.tar.gz xpm-3.5.1-1-doc.zip coreutils-5.3.0-doc.zip jpeg-6b-4-bin.zip texinfo-4.8-bin.zip xpm-3.5.1-1-lib.zip coreutils-5.3.0-src.zip jpeg-6b-4-dep.zip texinfo-4.8-dep.zip xpm-3.5.1-1-src.zip findutils-4.2.20-2-bin.zip jpeg-6b-4-doc.zip texinfo-4.8-doc.zip zlib-1.2.3-bin.zip findutils-4.2.20-2-dep.zip jpeg-6b-4-lib.zip texinfo-4.8-src.zip zlib-1.2.3-doc.zip findutils-4.2.20-2-doc.zip jpeg-6b-4-src.zip tiff-3.8.2-bin.zip zlib-1.2.3-lib.zip findutils-4.2.20-2-src.zip libpng-1.2.8-bin.zip tiff-3.8.2-dep.zip zlib-1.2.3-src.zip Next in path is cygwin and the usual Windows stuff. Given this setup here are some version strings: C:\Users\deyke\emacs-build>set PATH=C:\MinGW\bin;C:\Users\deyke\emacs-build\\bin ;C:\Program Files\Wonderful;.;tools;c:\Users\deyke\.bin;C:\cygwin\bin;C:\cygwin\ usr\X11R6\bin;C:\Python24;C:\Python24\Scripts;C:\emacs\bin;C:\Program Files\Micr osoft IntelliType Pro;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C: \Program Files\OpenVPN\bin;C:\Program Files\mplayer;C:\Program Files\Executive S oftware\Diskeeper;C:\Software\Unison;C:\Program Files\Subversion\bin;C:\Program Files\Aspell\bin;C:\Program Files\QuickTime\QTSystem C:\Users\deyke\emacs-build>gcc --version gcc (GCC) 3.2.3 (mingw special 20030504-1) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Users\deyke\emacs-build>make --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Users\deyke\emacs-build>sh --version GNU bash, version 3.00.16(14)-release (i686-pc-cygwin) Copyright (C) 2004 Free Software Foundation, Inc. -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> From: Dieter Deyke <[EMAIL PROTECTED]>
>> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
>> Date: Sat, 25 Mar 2006 08:54:45 -0700
>>
>> The strange thing is that the error vanished yesterday on my work PC,
>> but using the same tools I still get it on my home PC:
>
> Do you have the same sources (i.e. the same CVS check-out) on both of
> these machines?
I'm not sure, but I guess so. The error vanished on my work PC with
CVS sources from yesterday afternoon, and it is still here on my home
PC with CVS sources from this morning.
>
>> Starting program: C:\Users\deyke\emacs-build\work\lisp/../bin/my-emacs.exe
>> -batc
>> h --no-init-file --no-site-file --multibyte -f batch-byte-compile
>> url/vc-dav.el
>>
>> Breakpoint 3, get_doc_string (filepos=-2581128, unibyte=0, definition=0)
>> at doc.c:196
>> 196 error ("Cannot open doc string file \"%s\"", name);
>> (gdb) up 1
>> #1 0x0110da05 in Fdocumentation (function=27819993, raw=27674673) at
>> doc.c:456
>> 456 tem = get_doc_string (doc, 0, 0);
>> (gdb) print function
>> $1 = 27819993
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $2 = (struct Lisp_Symbol *) 0x1a87fd8
>> "file-exists-p"
>> (gdb)
>
> Thanks. Now please repeat this again, and this time put a breakpoint
> in Fdocumentation; when it breaks, verify that the first argument is
> indeed file-exists-p, and then step through the code until it calls
> get_doc_string and tell me what you saw. When I do that on my system,
> what I see is below. As you see, Fdocumentation returns nil without
> ever calling get_doc_string. Can you find out what is different on
> your machine, and why?
>
>> As for your last question, I'm not using MSYS. My setup includes:
>>
>> english XP Pro SP2
>> current cygwin
>> MinGW-3.1.0-1 in PATH before cygwin
>
> Okay, so perhaps Cygwin has something to do with this. Hopefully, we
> will understand that when we find the reason for the different
> behavior.
>
> Here's a transcript of the GDB session on my machine:
>
> D:\gnu\test\emacs\lisp>gdb ../bin/bootstrap-emacs.exe
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32"...
> (gdb) br Fdocumentation
> Breakpoint 1 at 0x10fc4e0: file doc.c, line 378.
> (gdb) source ../src/.gdbinit
> Environment variable "DISPLAY" not defined.
> Environment variable "TERM" not defined.
> Breakpoint 2 at 0x1133856: file w32fns.c, line 8965.
> Breakpoint 3 at 0x109513b: file sysdep.c, line 1395.
> (gdb) del 2 3
> (gdb) r -batch --no-init-file --no-site-file --multibyte -l loaddefs.el -f
> batc
> h-byte-compile url/vc-dav.el
> Starting program: D:\gnu\test\emacs\lisp/../bin/bootstrap-emacs.exe -batch
> --no
> -init-file --no-site-file --multibyte -l loaddefs.el -f batch-byte-compile
> url/v
> c-dav.el
> Loading subst-ksc...
> Loading subst-gb2312...
> Loading subst-big5...
> Loading subst-jis...
>
> Breakpoint 1, Fdocumentation (function=44196825, raw=44054577) at doc.c:378
> 378 int try_reload = 1;
> (gdb) p function
> $1 = 44196825
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0x2a263d8
> "file-exists-p"
> (gdb) n
> 374 {
> (gdb) n
> 384 if (SYMBOLP (function)
> (gdb)
> 382 doc = Qnil;
> (gdb)
> 384 if (SYMBOLP (function)
> (gdb)
> 382 doc = Qnil;
> (gdb)
> 384 if (SYMBOLP (function)
> (gdb)
> 389 fun = Findirect_function (function, Qnil);
> (gdb)
> 390 if (SUBRP (fun))
> (gdb)
> 392 if (XSUBR (fun)->doc == 0)
> (gdb)
> 409 return Qnil;
> (gdb)
> 477 }
> (gdb)
Breakpoint 4, Fdocumentation (function=27819993, raw=27674673) at doc.c:378
378 int try_reload = 1;
(gdb) p function
$3 = 27819993
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$4 = (struct Lisp_Symbol *) 0x1a87fd8
"file-exists-p"
(gdb) n
374 {
(gdb) n
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
382 doc = Qnil;
(gdb)
384 if (SYMBOLP (function)
(gdb)
389 fun = Findirect_function (function, Qnil);
(gdb)
390 if (SUBRP (fun))
(gdb)
392 if (XSUBR (fun)->doc == 0)
(gdb)
394 else if ((EMACS_INT) XSUBR (fun)->doc >= 0)
(gdb)
397 doc = make_number ((EMACS_INT) XSUBR (fun)->doc);
(gdb)
451 if (EQ (doc, make_number (0)))
(gdb)
453 if (INTEGERP (doc) || CONSP (doc))
(gdb)
456 tem = get_doc_string (doc, 0, 0);
(gdb)
Breakpoint 3, get_doc_string (filepos=-2581128, unibyte=0, definition=0)
at doc.c:196
196 error ("Cannot open doc string file \"%s\"", name);
(gdb)
--
Dieter Deyke
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: old bootstrap error emerges again
> Eli Zaretskii <[EMAIL PROTECTED]> writes: > >> 390 if (SUBRP (fun)) >> (gdb) >> 392 if (XSUBR (fun)->doc == 0) >> (gdb) >> 409 return Qnil; >> (gdb) >> 477 } >> (gdb) Dieter Deyke <[EMAIL PROTECTED]> writes: > 390 if (SUBRP (fun)) > (gdb) > 392 if (XSUBR (fun)->doc == 0) > (gdb) > 394 else if ((EMACS_INT) XSUBR (fun)->doc >= 0) Could it be that we are not explicitly setting doc to 0, and Dieter's compiler is initializing its memory with something other than 0 to detect this type of bug? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: old bootstrap error emerges again
Jason Rumney <[EMAIL PROTECTED]> writes: >> Eli Zaretskii <[EMAIL PROTECTED]> writes: >> >>> 390 if (SUBRP (fun)) >>> (gdb) >>> 392 if (XSUBR (fun)->doc == 0) >>> (gdb) >>> 409 return Qnil; >>> (gdb) >>> 477 } >>> (gdb) > > Dieter Deyke <[EMAIL PROTECTED]> writes: > >> 390 if (SUBRP (fun)) >> (gdb) >> 392 if (XSUBR (fun)->doc == 0) >> (gdb) >> 394 else if ((EMACS_INT) XSUBR (fun)->doc >= 0) > > Could it be that we are not explicitly setting doc to 0, and Dieter's > compiler is initializing its memory with something other than 0 to > detect this type of bug? All List_Subr's are statically allocated, it would be a compiler bug if they wouldn't be properly initialized. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
