mt> as it seems the behavior of --pdump has change. So now as opposed to mt> 21.2.26 I get temacs and xemacs both with the same size: mt> -rwx------ 1 thiessel thiessel 5159408 Feb 7 18:01 temacs mt> -rwx------ 1 thiessel thiessel 5159408 Feb 7 17:59 xemacs Yes, I did that... mt> The build process fails at mt> MAKE='make' EMACS='./src/xemacs' /bin/sh /ux/xemacs-21.2.28/lib-src/update-elc.sh mt> (using ./src/xemacs) mt> Recompiling in /ux/xemacs-21.2.28 mt> with /ux/xemacs-21.2.28/src/xemacs... mt> temacs can only be run in -batch mode. mt> *** Error exit code 255 I think you'll find if you do cd src; rm temacs xemacs; make you'll get a runnable xemacs. Well, we need to have an actual strategy for how temacs should differ from xemacs, or whether such a distinction is necessary. Several strategies are available: - xemacs/temacs looks at its executable name, and runs pdump_load only if not named temacs. This sort of thing is known to be evil. - we create files pre-dump.c and post-dump.c pre-dump.c: int load_dump_file_p = 0; post-dump.c: int load_dump_file_p = 1; We link temacs with pre-dump.o and xemacs with post-dump.o to create similar but different executables. This wastes 7mb of disk. - We use a command-line option -no-dumped-data-file, and change the Makefiles to do things like ./xemacs -no-dumped-data-file -batch -l ../lisp/update-elc.el Then we would never have a `temacs'. Olivier?

Martin Buchholz writes: Right, that works. I thought somebody changed the build process to go beyond this point and something else was failing. But it's old story ... Is that what we are looking for indeed!? If there is no temacs (at least I like to force it) debugging the dump on new architectures would be more difficult. --Marcus