Re: Unable to install 21.4.1 to Debian GNU/Linux x86 potato

Hannu Koivisto <azure(a)iki.fi&gt; writes: | Loading | .../xemacs-21.4-compiled/src/../lisp/make-docfile.el... | Loading very-early-lisp... | Loading find-paths.el... | Loading packages.el... | Loading setup-paths.el... | Loading dump-paths.el... | Loading .../xemacs-21.4-compiled/lisp/dumped-lisp.el... | | "Error: Library file backquote not found" | rm -f ../lib-src/DOC; \ I tinkered a bit with debug external-debugging-output+formats and I think I know why that loading fails. I produced this result with `EMACSDEBUGPATHS=t make': Loading /home/azure/projects/software/3rdparty/xemacs-21.4-compiled/src/../lisp/update-elc.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... XEmacs thinks the roots of its hierarchy are: ("/home/azure/projects/software/3rdparty/xemacs-21.4-compiled/") configure-package-path: nil late-packages and late-package-load-path: ("/home/azure/projects/software/3rdparty/xemacs-packages/" "/home/azure/projects/software/3rdparty/xemacs-packages/comm/" "/home/azure/projects/software/3rdparty/xemacs-packages/games/" "/home/azure/projects/software/3rdparty/xemacs-packages/libs/" "/home/azure/projects/software/3rdparty/xemacs-packages/mule/" "/home/azure/projects/software/3rdparty/xemacs-packages/oa/" "/home/azure/projects/software/3rdparty/xemacs-packages/os/" "/home/azure/projects/software/3rdparty/xemacs-packages/prog/" "/home/azure/projects/software/3rdparty/xemacs-packages/wp/") nil lisp-directory: "/usr/local/xemacs-21.4/share/xemacs-21.4.1/lisp/" mule-lisp-directory: nil module-directory: "/usr/local/xemacs-21.4/share/xemacs-21.4.1/i686-pc-linux/modules/" site-module-directory: nil ---------load-path now: (/usr/local/xemacs-21.4/share/xemacs-21.4.1/lisp/) Loading /home/azure/projects/software/3rdparty/xemacs-21.4-compiled/lisp/dumped-lisp.el... "Error: Library file backquote not found" The line beginning with "-----" is printed by my code just after `(load "dump-paths.el")' in update-elc.el. The load-path is wrong; somehow the future installation root has been substituted in place of the source root. Does the output generated by dump-paths.el due to EMACSDEBUGPATHS help anyone to figure out what goes wrong? I'm afraid the logic in dump-paths.el is a bit too hairy for me to reverse engineer, especially because I don't really know what the contents of all those different path variables should be at this point (or at any point). -- Hannu Please don't send copies of list mail