On Wednesday, 9 October 2002, Martin Costabel wrote: PowerPC is a big-endian machine. Is it possible that some sign comparison is causing an infinite loop ? Why don't you try compiling with all warnings turned on, remove the optimizations completely and see if something fishy turns up ? The default options for XEmacs are not strict enough. Try with -Wall -W -Wpointer-arith. And remove the -O3 which gets tagged on along with -g, as it is useless. Any program which allocates 65536 KB on the stack is stupid. And I am sure XEmacs is not. Hope this helps. -kitty. -- Krishnakumar B <kitty at cs dot wustl dot edu> Distributed Object Computing Laboratory, Washington University in St.Louis

robert delius royar wrote: Thanks, this might get me on the right track. These options are completely different from those used by the fink package (see below). I cannot use your options directly, I get some undefined symbols error from the libXm library, probably because of a lesstif vs motif problem. But if I replace your 'lucid' by 'athena', then 21.5.9 with your options does compile! I am now in a long (every compilation takes ~ 20 minutes) elimination process of trying to find the precise option that breaks the compilation and gives me the bus error. Here are the options used by fink for 21.5.9: --with-dialogs=athena --with-widgets=athena --with-sound=none --with-database=no --without-ldap --without-postgresql --with-athena=3d --error-checking=none -- Martin

Martin> Martin Costabel wrote: Martin> [] Martin> Preliminary answer: It's the --error-checking=none option Martin> that causes the failure. Adding all of fink's options to Martin> yours except this one lets the build process go through Martin> without error, adding this option produces a crash at the Martin> same point as before. Martin> I don't get the same error message, though, so the precise Martin> failure mechanism seems to depend also on the other Martin> options. The error message I am getting now is (on both Martin> machines that earlier had different error messages) Martin> Dumping under the name xemacs Martin> Testing for Lisp shadows ... Martin> Symbol's value as variable is void: tables Martin> xemacs exiting Martin> . Martin> make[1]: *** [xemacs.dmp] Error 255 Martin> I have no idea, of course, what is going on here, so I Martin> would still be interested to hear an explanation from the Martin> experts. I did send a complete C backtrace from the 'bus Martin> error' in my first message. The other errors "Symbol's Martin> value as variable is void: frames" or "... tables" don't Martin> produce backtraces. Hi Martin, the latter are lisp errors. Please provide the commands executed by make before the above error. Try putting these lines (setq debug-on-error t) (setq debug-on-quit t) (setq debug-on-signal t) at the beginning of the .el file loaded on the command-line (perhaps update-elc-2.el ?) of the failing command and run make again. Send us the backtrace. Hope this helps, Adrian Martin> -- Martin> Martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Martin> Adrian Aichner wrote: Martin> Sorry to be somewhat obtuse, but the GNUMakefile is not very Martin> forthcoming about what it is doing. The most probable command executed Martin> is Martin> ./xemacs -batch -f list-load-path-shadows Ah, the file in question is lisp\shadow.el Try putting my variable definitions at the beginning of that one, remove shadow.elc, and run the offending command. Martin> in the src subdirectory. Martin> I don't know how to get a backtrace out of this. If I Martin> execute it by hand in the builddir/src, it gives the same Martin> message and a return code of 255. In fact, any invocation Martin> of this new xemacs with whatever command-line option gives Martin> me the same message Martin> Symbol's value as variable is void: tables Martin> I tried to put -eval '(setq debug-on-error t)' etc on the Martin> command line, but this has no effect. Martin> OTOH, if I rm src/xemacs and then run "make" by hand, it Martin> recreates a new xemacs executable that seems to be Martin> correct, and make goes through to the end without Martin> error. This is really hard to catch <sigh>. Is that new xemacs fully functional? Can you start and use it as expected? Adrian Martin> -- Martin> Martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Martin> Adrian Aichner wrote: Martin> ./xemacs -batch -f list-load-path-shadows >> Ah, the file in question is >> lisp\shadow.el >> Try putting my variable definitions at the beginning of that one, >> remove shadow.elc, and run the offending command. Martin> No backtrace. This xemacs is not a standalone binary. It Martin> has an xemacs.dmp at its side. When run without it, it Martin> says "temacs can only be run in -batch mode." and Martin> quits. When xemacs.dmp is there, it starts up, puts Martin> "Symbol's value as variable is void: tables" in its Martin> minibuffer line, but seems to work otherwise. Does M-x show-message-log provide any clues? OK, try starting with xemacs -debug-init -debug-paths and send the output. Adrian Martin> -- Martin> Martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Martin> Adrian Aichner wrote: Martin> No. It says Martin> Recent minibuffer messages (most recent first): Martin> Symbol's value as variable is void: tables Martin> That's all. Martin> OK, here it is: Martin> [imac:]martin% ./xemacs -debug-init -debug-paths Martin> emacs-roots: Martin> ("/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/") Martin> arguments: Martin> roots: ("/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/") Martin> user-init-directory: "~/.xemacs/" Martin> inhibit-packages: nil Martin> inhibit-site-lisp: nil Martin> debug-paths: t Martin> called-early: nil Martin> configure-package-path: Martin> nil Martin> early-packages and early-package-load-path: Martin> nil Martin> nil Martin> late-packages and late-package-load-path: Martin> nil Martin> nil Martin> last-packages and last-package-load-path: Martin> nil Martin> nil Martin> lisp-directory: Martin> "/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lisp/" Martin> mule-lisp-directory: Martin> "/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lisp/mule/" Martin> site-directory: Martin> nil Martin> Info-directory-list: Martin> ("/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/info/" "/sw/share/info/" Martin> "/sw/info/" "/usr/local/share/info/" "/usr/local/lib/info/" Martin> "/usr/local/info/" "/usr/share/info/") Martin> exec-directory: Martin> /sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lib-src/ Martin> exec-path: Martin> ("/sw/share/Geomview/bin/" "/sw/bin/" "/sw/sbin/" Martin> "/Users/martin/bin/powerpc-apple-darwin/" "/Users/martin/bin/" Martin> "/usr/local/bin/" "/usr/bin/" "/bin/" "/usr/local/sbin/" "/usr/sbin/" Martin> "/sbin/" "/usr/X11R6/bin/" "/usr/local/X11/bin/" Martin> "/usr/local/lib/gcc-lib/powerpc-apple-darwin1.4/3.1/" Martin> "/usr/X11R6/bin/" "/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lib-src/") Martin> doc-directory: Martin> "/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lib-src/" Martin> data-directory: Martin> "/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/etc/" Martin> data-directory-list: Martin> ("/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/etc/") Martin> Does this help? Hi Martin, you have no packages at all installed? Not a problem for building XEmacs, but once it works, you'll probably want them. See item 7 to 15 in http://www.xemacs.org/Install/index.html or read after 15 how to get the sumos. Try starting xemacs -vanilla If that does not complain about Symbol's value as variable is void: tables then you have to see what in your .emacs, .xemacs/init.el, or .xemacs/custom.el (unlikely) is causing the lisp error. Hope this helps, Adrian Martin> -- Martin> Martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Martin> Adrian Aichner wrote: Martin> I do. Over 60MB of them. They are just not visible to this Martin> xemacs in its build directory. They are in /sw/lib/xemacs/ Martin> and they will be visible when xemacs is installed. I am Martin> not quite the newbie this problem makes me seem to be. I Please don't take offense when I make suggestions that seem too trivial. I am trying to help. Martin> have compiled xemacs on various systems from the times Martin> when it was called lemacs, and I am using it daily in my Martin> work. I did spend quite some time trying to debug this True believer, huh? Martin> myself before writing to the list, but I admit that it is Martin> over my head. Martin> There was also some discussion on the fink mailing lists Martin> about this problem, but no idea emerged, partly because no Martin> real xemacs experts were present, but mainly because this Martin> is something that only happens to some people and not to Martin> others, although they all use exactly the same build Martin> system with the same configure and compile options. Martin> It does. I have tried all command line option variants I Martin> can imagine. This error must be somewhere in the Martin> preloaded lisp packages or rather in their dumped Martin> form. But I am sure this error is only a symptom of Martin> something else, maybe a buffer overflow in the dump Martin> process or something. What about the compiler you use? Could it be the problem? Have you tried compiling with less or no optimization? Martin> In fact, here is a suspicion: Is it possible that the list Martin> of filenames in the dumped xemacs can get too long? I find Don't know. Martin> there more than 10000 bytes of filenames of the form Martin> /Volumes/Software/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lisp/post-gc.elc Martin> /Volumes/Software/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lisp/replace.elc Martin> /Volumes/Software/sw/src/xemacs-21.5.9-1/xemacs-21.5.9/lisp/cmdloop.elc Martin> and so on. Martin> As I have tried to explain before, if I compile with Martin> slightly different options, I get a crash at the same Martin> place, but with different error messages. Depending on the Martin> options, this can be a lisp error or a C error (bus Martin> error). When I omit the option '--error-checking=none', Martin> then the compilation terminates successfully. When I run Martin> "make" by hand from the command line, I get a different Martin> result from when I run the same make from inside the fink Martin> build script. Martin> I also compared build output logs from a successful build Martin> and an unsuccessful one. Apart from some lines that Martin> acknowledge the activated error checking, the two outputs Martin> are strictly identical up to the fatal error around line Martin> 1655 or so. Martin, please send us build reports, if possible. Do you have a fully functional XEmacs on your system? You could use my build XEmacs package to try building the new version. It will save output from various build steps and offer to send them in a build report at the end. If that's too much, please send us Installation, configure output, make output All for the build exposing the build problem. Best regards, Adrian Martin> -- Martin> Martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Adrian Aichner wrote: No offense taken. I hope you don't either :-) I am very grateful for your patience. It is just that this xemacs build process is so complex that there exist 1000s of possibilities, and I try to steer the discussion to what I think might be essential. I can be wrong, of course, and this whole thing is just caused by some dumb mistake that I am making. After banging my head against this for 2 weeks, getting heartburn from reading too much lisp, and still not knowing whether Bytecount is the same type as size_t, I would be happy to hear this. Or too lazy to learn a new editor each time I get a new computer on my desk ;-) I used gcc-2.95.2 and gcc-3.1 as supplied by Apple. Same result exactly. OK, for two cases where this breaks (one where the result is "Symbol's value as variable is void: tables" and one where the result is a bus error) I have prepared the describe-installation output and the complete build log. In the second case also an enhanced C backtrace from gdb. Since this is more than 200kB, I have put the files on the web in the directory http://www.maths.univ-rennes1.fr/~costabel/xemacsbug/ Thanks -- Martin