Bootstrap problem.

Bootstrap problem.

[Lute Kamstra]

Consider the following situation.

Add a definition to lisp file A and make it available to other lisp
files by adding an autoload cookie.  Commit the change.  Then add some
code to lisp file B that depends on the presence of this definition to
compile.  Commit this change as well.

As I found out the hard way, this leads to problems in two cases:

1. Someone does a fresh checkout from CVS and does a make bootstrap.
   This fails because bootstrap-emacs that tries to compile file B
   uses the autoloads in ldefs-boot.el which wasn't updated and thus
   doesn't contain an autoload of the required definition in file A.

   This can, of course, be solved by regenerating ldefs-boot.el and
   committing it.  It's probably a good idea to mention this
   explicitly somewhere.

2. Someone has a CVS tree and did the last update before the change in
   file A.  Then that person does per next update after the change to
   file B and then does a make bootstrap.  bootstrap-emacs uses the
   old loaddefs.el that does not contain an autoload of the required
   definition in file A and fails to compile file B.

   A second make bootstrap would work fine as this would use the new
   loaddefs.el that was created during the first make bootstrap that
   failed.

Can't the bootstrap process be changed so that bootstrap-emacs uses
loaddefs.el with autoloads that are up to date?  This would make
ldefs-boot.el obsolete and one wouldn't have to think about
regenerating it under some circumstances.  It would also solve the
second problem.

Lute.

Re: Bootstrap problem.

[Kim F. Storm]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Consider the following situation.
>
> Add a definition to lisp file A and make it available to other lisp
> files by adding an autoload cookie.  Commit the change.  Then add some
> code to lisp file B that depends on the presence of this definition to
> compile.  Commit this change as well.

I don't see why you cannot simply add

  (eval-when-compile
    (require 'A))

to B.  

Since A will be loaded anyway due to the autoload cookie, it doesn't
cost anything, and it makes it clear that B uses features of A.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bootstrap problem.

[Lute Kamstra]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Add a definition to lisp file A and make it available to other lisp
> files by adding an autoload cookie.  Commit the change.  Then add
> some code to lisp file B that depends on the presence of this
> definition to compile.  Commit this change as well.
>
> As I found out the hard way, this leads to problems in two cases:

[...]

> 2. Someone has a CVS tree and did the last update before the change in
>    file A.  Then that person does per next update after the change to
>    file B and then does a make bootstrap.  bootstrap-emacs uses the
>    old loaddefs.el that does not contain an autoload of the required
>    definition in file A and fails to compile file B.
>
>    A second make bootstrap would work fine as this would use the new
>    loaddefs.el that was created during the first make bootstrap that
>    failed.

Strange: I just looked more carefully at the bootstrap process and it
seems that this second problem should not occur.  From what I now
understand, bootstrap already does what I want: it first updates
loaddefs.el and then builds bootstrap-emacs and dumps it with the
up-to-date loaddefs.el loaded.

But now I don't know how to explain Chris Moore's recent bug report on
emacs-pretest-bug.

Lute.

Re: Bootstrap problem.

[Lute Kamstra]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> Add a definition to lisp file A and make it available to other lisp
>> files by adding an autoload cookie.  Commit the change.  Then add
>> some code to lisp file B that depends on the presence of this
>> definition to compile.  Commit this change as well.
>>
>> As I found out the hard way, this leads to problems in two cases:
>
> [...]
>
>> 2. Someone has a CVS tree and did the last update before the change in
>>    file A.  Then that person does per next update after the change to
>>    file B and then does a make bootstrap.  bootstrap-emacs uses the
>>    old loaddefs.el that does not contain an autoload of the required
>>    definition in file A and fails to compile file B.
>>
>>    A second make bootstrap would work fine as this would use the new
>>    loaddefs.el that was created during the first make bootstrap that
>>    failed.
>
> Strange: I just looked more carefully at the bootstrap process and it
> seems that this second problem should not occur.  From what I now
> understand, bootstrap already does what I want: it first updates
> loaddefs.el and then builds bootstrap-emacs and dumps it with the
> up-to-date loaddefs.el loaded.
>
> But now I don't know how to explain Chris Moore's recent bug report on
> emacs-pretest-bug.

I figured it out: a make clean deletes the emacs executable, but not
loaddefs.el.  So a subsequent make bootstrap cannot use the old emacs
to regenerate loaddefs.el and bootstrap-emacs uses the old loaddefs.el
to compile the new lisp files.

We could let make clean delete loaddefs.el as well.  Or would that
have any negative effects that I'm not aware of?

Lute.

Re: Bootstrap problem.

[Richard Stallman]

    We could let make clean delete loaddefs.el as well.  Or would that
    have any negative effects that I'm not aware of?

`make clean' should not delete loaddefs.el because that file is part
of the Emacs distribution.  However, if we want to change
bootstrapping to delete loaddefs.el at some stage, that's ok.  Just
don't put it inside of `make clean'.

bootstrap problem

[djh]

Eli, et al,

Here is the latest results attempting to make a boostrap with the latest cvs on cygwin 5.19. I attempted to run the line of code that broke (dumped the core) and repeat it.  See results below:

------
Compiling /cygdrive/c/emacs/cvs/emacs/lisp/emacs-lisp/byte-opt.el
Fatal error (6)/bin/sh: line 1:  1388 Aborted                 (core dumped) EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done $el
make[2]: *** [compile] Error 1

------
Then by hand
$ cd ...cvs/emacs/src
$ export EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp
$ ./bootstrap-emacs.exe -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done byte-opt.el

Fatal error (6)zsh: abort (core dumped)  ./bootstrap-emacs.exe -batch --no-site-file --multibyte -f  byte-opt.el

Any ideas or advice to get more data to isolate the problem is appreciated.

Regards,
  Darel Henman

Re: bootstrap problem

[Eli Zaretskii]

> From: "djh" <henman@it.to-be.co.jp>
> Date: Thu, 25 May 2006 13:33:49 +0900
> cc: 
> 
> Then by hand
> $ cd ...cvs/emacs/src
> $ export EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp
> $ ./bootstrap-emacs.exe -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done byte-opt.el
> 
> Fatal error (6)zsh: abort (core dumped)  ./bootstrap-emacs.exe -batch --no-site-file --multibyte -f  byte-opt.el
> 
> Any ideas or advice to get more data to isolate the problem is appreciated.

Now that we know which command crashes, run it under GDB:

 $ cd ...cvs/emacs/src
 $ export EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp
 $ gdb ./bootstrap-emacs.exe
 $ run -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done byte-opt.el

Now when Emacs crashes, GDB will get control.  Then type these two
commands:

  (gdb) backtrace
  (gdb) xbacktrace

and tell what they print.

TIA

Re: bootstrap problem

[djh]

Eli et al,
  here is some more information about the cygwin 5.19 + x-window build status.

> Now that we know which command crashes, run it under GDB:
> 
>  $ cd ...cvs/emacs/src
>  $ export EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp
>  $ gdb ./bootstrap-emacs.exe
>  $ run -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done byte-opt.el
> 
 export EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp
prc[0]:cvs/emacs/src $ gdb ./bootstrap-emacs.exe
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
Environment variable "DISPLAY" not defined.
TERM = xterm
Breakpoint 1 at 0x200a1076: file emacs.c, line 464.
Breakpoint 2 at 0x200ba389: file sysdep.c, line 1395.
(gdb) run -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done byte-opt.el
Starting program: /cygdrive/c/emacs/cvs/emacs/src/bootstrap-emacs.exe -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done byte-opt.el
---Type <return> to continue, or q <return> to quit---

Program received signal SIGSEGV, Segmentation fault.
0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll

----
> Now when Emacs crashes, GDB will get control.  Then type these two
> commands:
> 
>   (gdb) backtrace
>   (gdb) xbacktrace
> 
> and tell what they print.
> 

(gdb) backtrace
#0  0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll
#1  0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll
#2  0x00000003 in ?? ()
#3  0x0022ee18 in ?? ()
#4  0x00000001 in ?? ()
#5  0x0022ee18 in ?? ()
#6  0x0022ee38 in ?? ()
#7  0x200a2100 in main (argc=539893664, argv=0x4) at emacs.c:1062

Lisp Backtrace:
0x0 Lisp type 0
Cannot access memory at address 0x0

xbacktrace
0x0 Lisp type 0
Cannot access memory at address 0x0

Regards,
  Darel Henman

Re: bootstrap problem

[Eli Zaretskii]

> Cc: "djh" <henman@it.to-be.co.jp>, <emacs-devel@gnu.org>
> From: "djh" <henman@it.to-be.co.jp>
> Date: Fri, 26 May 2006 13:47:58 +0900
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll

So Emacs does, indeed, crash.  However, your previous transcript
indicated it was a SIGABRT, not SIGSEGV:

> Fatal error (6)zsh: abort (core dumped)  ./bootstrap-emacs.exe -batch --no-site-file --multibyte -f  byte-opt.el

Signal 6 is SIGABRT, IIRC.

> (gdb) backtrace
> #0  0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll
> #1  0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll
> #2  0x00000003 in ?? ()
> #3  0x0022ee18 in ?? ()
> #4  0x00000001 in ?? ()
> #5  0x0022ee18 in ?? ()
> #6  0x0022ee38 in ?? ()
> #7  0x200a2100 in main (argc=539893664, argv=0x4) at emacs.c:1062

Ouch!  Was your Emacs compiled with "-gdwarf-2 -g3" compiler switches?
If not, please reconfigure to use these and rebuild.  It will be very
hard to debug this without a reliable debug info.  Also, please make
sure you have the latest version of GDB available under Cygwin.  If
there's a version of cygwin1.dll with full debug info, please use that
as well in your next trials.

If none of the above helps to get a more meaningful backtrace, I'm
afraid you will need to ask on the Cygwin list for more help.  We need
some way of getting a meaningful backtrace, to know where Emacs
crashes, and I don't know enough about Cygwin internals to suggest how
to get it, except with the above advice.

> Lisp Backtrace:
> 0x0 Lisp type 0
> Cannot access memory at address 0x0
> 
> xbacktrace
> 0x0 Lisp type 0
> Cannot access memory at address 0x0

This is expected when C-level backtrace is garbled as above.

Thanks.