Re: [Bug: 21.5-b27] startup.el "borks" filepath?

Mon, 20 Nov 2006 (11:35 +0900 UTC) Stephen J. Turnbull wrote: 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. 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. Yes, it is 10.4.8 with the latest revisions to gcc. The processor is a g5, and I do not use the universal SDKs, so I am not creating a multi-architecture executable. By the way, it is probably not an error, but I have been seeing the following in my configure since the mailing list reactivated: checking for compiler version information... powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) checking for standard C library version information... checking for runtime libraries flag... sed: conftest.c: No such file or directory sed: conftest.c: No such file or directory sed: conftest.c: No such file or directory NONE -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky Making meaning one message at a time. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta