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

[Artemio Gonzalez Lopez]

robert delius royar wrote:
> 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.

Hi everybody,

I had exactly the same problem as Robert with startup.el, but I think 
the circumstances in which the problem arose in in my case may shed 
light on the whole issue. I have 3 machines running OS X 10.4.8, on all 
of which xemacs is regularly installed in /opt/local using the following 
options:

./configure --prefix=/opt/local --infodir=/opt/local/share/info 
--mandir=/opt/local/share/man --with-site-prefixes=/opt/local 
--disable-error-checking --with-ldap=no --with-postgresql=no 
--with-default-eol-detection --without-mule --with-tty --with-ncurses 
--with-scrollbars=motif --with-dialogs=motif --with-widgets=motif 
--with-optimization

On two of them I have been able to install the 20061123 CVS xemacs 
21.5.27 normally. The problem arose in the third machine, when I first 
(succesfully) moved the installation of xemacs to /usr/local (removing, 
among other things, the --prefix option) and then (after deleting this 
installation) tried to rebuild xemacs and install it back in /opt/local. 
This has proved altogether impossible because of the problem with 
startup.el (make fails with exactly the same error as Robert reported). 
I even deleted the whole xemacs-21.5.27 source tree and copied it from 
one of the machines which didn't suffer from this problem, to no avail. 
The next thing I tried, on Robert's suggestion, was adding the following 
options to configure:

--datarootdir=/opt/local/lib --datadir=/opt/local/lib

Now make goes much farther, almost to the end, but fails at the very 
last minute with the following error:

Compiling 
/Users/artemio/Archive/xemacs/xemacs-21.5.27/lisp/custom-load.el...
Wrote /Users/artemio/Archive/xemacs/xemacs-21.5.27/lisp/custom-load.elc
Building finder database ...
rm -f /Users/artemio/Archive/xemacs/xemacs-21.5.27/src/../lisp/finder-inf.el
./xemacs -no-packages -batch    -eval "(setq 
finder-compile-keywords-quiet t)" \
         -l finder -f finder-compile-keywords

   Requiring finder-inf... (file finder-inf.el is newer)

xemacs exiting.
Buffer is read-only: #<buffer "finder-inf.el">make[1]: *** 
[/Users/artemio/Archive/xemacs/xemacs-21.5.27/src/../lisp/finder-inf.el] 
Error 255
make: *** [src] Error 2

I would really appreciate if somebody suggested a workaround either for 
this or for the original problem with startup.el, since I have no idea 
what to try next.

Cheers,

Artemio