emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loaddefs.el on Windows incomplete


From: Eli Zaretskii
Subject: Re: loaddefs.el on Windows incomplete
Date: Mon, 26 Dec 2005 21:11:20 +0200

> Cc: address@hidden
> From: Ralf Angeli <address@hidden>
> Date: Mon, 26 Dec 2005 16:56:17 +0100
> 
> Thanks for your efforts.  I did a fresh checkout into a new directory,
> ran `configure ...' and while doing `mingw32-make bootstrap' the
> following error occurred:
> 
> --8<---------------cut here---------------start------------->8---
> "./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l 
> autoload \
>         --eval '(setq find-file-hook nil 
> find-file-suppress-same-file-warnings t)' \
>         -f w32-batch-update-autoloads 
> "D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el" . 
> calc calendar emacs-lisp emulation eshell gnus international language mail 
> mh-e net obsolete play progmodes term textmodes url
> 
> Wrong type argument: symbolp, 0
> mingw32-make[1]: *** [autoloads] Error -1
> mingw32-make[1]: Leaving directory 
> `D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp'
> mingw32-make: *** [bootstrap-gmake] Error 2
> --8<---------------cut here---------------end--------------->8---

A weird error.

> In order to get a backtrace I set `debug-on-error' to t via the --eval
> statement above.  That means I edited lisp/makefile.w32-in
> accordingly and ran `configure' again.  Interestingly the error did
> not occur with this change.  I tried this both in the directory where
> the make call failed with the original makefile.w32-in and in a
> directory which had not seen a make call before.  Same results.

Still weirder.  But see below.

> Then I tried to run `mingw32-make bootstrap' in a freshly checked out
> and configured directory including the patch I proposed for
> lisp/makefile.w32-in and got the same error as above.

So the problem doesn't seem to be due to the changes, but to something
else.  Did you remember to check out the Emacs tree with the -kb
switch to the "co" command?  If not, perhaps what you see is due to
some EOL-related snafu.

> Let-binding `debug-on-error' to t made the error vanish again.  Now
> I don't really know where to look for the cause of the error.

How about editing lisp/makefile so that Emacs displays its
command-line arguments (via `message') before doing anything else?
Something like this:

 "./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l 
autoload \
         --eval '(message "%s" command-line-args)'
         --eval '(setq find-file-hook nil find-file-suppress-same-file-warnings 
t)' \
         -f w32-batch-update-autoloads 
"D:/software/windows/unix/src/emacs-22.0.50-clean-build/lisp/loaddefs.el" . 
calc calendar emacs-lisp emulation eshell gnus international language mail mh-e 
net obsolete play progmodes term textmodes url

What does it print, if you try this?

If this makes the problem go away, please pay attention to the EOL
format of the files that get concatenated into makefile: gmake.defs,
the preamble produced by configure.bat, and makefile.w32-in.

> Anyway, in the directories where the build succeeded I did a `diff -u
> loaddefs.el ldefs-boot.el' which showed no differences between the
> files.

That's because loaddefs.el never go created, due to the error.  Since
bootstrap first copies ldefs-boot.el into loaddefs.el, it is expected
that they both be identical if the real loaddefs.el fails to be
created.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]