Mon, 20 Nov 2006 (11:35 +0900 UTC) Stephen J. Turnbull wrote: > Thanks for the report, and thank you for localizing it this far! I > need to clean up some stuff before I can properly try to reproduce it > (tonight, I think), but the following information may help me. > They're all just clarifications, not intended to point to an actual > suspect. I have found one show stopper that I could fix. Adding the line datarootdir=＠datarootdir＠ to Makefile.in.in lib-src/Makefile.in.in lib-src/config.values.in leads to a dumped xemacs that will run in place. Configure warned that these files seemed to ignore datarootdir Issuing a make install fails on the third iteration of the loadup code. However, doing make prefix=/Users/royar/usr/local \ datarootdir=/Users/royar/usr/local/lib \ datadir=/Users/royar/usr/local/lib install installs a working XEmacs in ~/usr/local/bin and all the other parts in ~/usr/local/lib, which is where they used to reside. I am suspecting based on files and directories created when prefix is not set, that there is a new hierachy for installation recommended, and that somewhere in the code that creates the hierarchy there needs to be a check for prefix being set by user preference. Because the install can get through a few iterations before failing, I suspect the last failure occurs because having prefix set makes it so that some file (or path) startup.el needs is not being seen. I would look for a variable that should be referencing a user-set preference but is not--probably datadir or datarootdir. > robert delius royar writes: > > > This bug showed up yesterday with the 20061116 CVS. Compilation > > occurs as normal, and temacs links. However, when temacs first > > loads with the command ./temacs -nd -no-packages -batch -l > > /Users/royar/src/xemacs/src/../lisp/update-elc.el it aborts after > > loading startup.el saying that it cannot find the file listed in > > preloaded-file-list immediately following startup.el. > > The only recent change to startup.el is Malcolm's change to the > startup screen code. I suppose this could result in a change in > XEmacs's default-directory, but it's strange that it wouldn't affect > everybody. > > When was the previous build (if you have that as your working XEmacs, > it should be available in M-X emacs-version and M-X > describe-installation)? > Do you have an XEmacs installed in /Users/royar/usr/local already? > Does that directory already exist and have reasonable permissions? > Have you tried with any other explicit --prefix settings? The last build that was successful (without the change to the config/make files) was 20061114; however, there is a caveat: I first discovered the error rebuilding 20061114 when I wanted to try the edit to gnuclient.c you had posted answering another user's query (because I also wanted to use local sockets). First, the install failed, and then I could not get the initial dump to work. It took a few days to to see that the make install had created a few new directories in ~/usr/local. I suspect that the code (seeing that ~/usr/local/xemacs and ~/usr/local/share existed) may have been searching them, but I have no evidence other than the effect to support this.