Re: make bootstrap fails with newest CVS sources - 2002-11-25

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Ben Key]

I have done some work on narrowing down what change was responsible for
breaking make bootstrap.  Here are my results thus far.

After cvs update -D "3 days ago" make bootstrap works.

After cvs update -D "2 days ago" make bootstrap does not work.

This means that whatever caused make bootstrap to fail happened in the last
2 days.

Here is a list of files that were changed in the last 2 days:
  etc/PROBLEMS
  lisp/ChangeLog
  lisp/international/code-pages.el
  lisp/language/cyrillic.el
  lisp/language/european.el
  src/ChangeLog
  src/Makefile.in
  src/alloca.c
  src/lisp.h
  src/unexalpha.c
  src/unexmacosx.c
  src/w32.c
  src/m/ia64.h

I am assuming that we can ignore the following:
  etc/PROBLEMS
  lisp/ChangeLog
  src/ChangeLog
  src/Makefile.in

Therefore, it is most likely that a change to one of the following is at
fault:
  lisp/international/code-pages.el
  lisp/language/cyrillic.el
  lisp/language/european.el
  src/alloca.c
  src/lisp.h
  src/unexalpha.c
  src/unexmacosx.c
  src/w32.c
  src/m/ia64.h

I will let you all know if I have any more luck.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Jason Rumney]

Ben Key <BenK@FreedomScientific.com> writes:

> I have done some work on narrowing down what change was responsible for
> breaking make bootstrap.  Here are my results thus far.

> After cvs update -D "3 days ago" make bootstrap works.
> 
> After cvs update -D "2 days ago" make bootstrap does not work.
> 
> This means that whatever caused make bootstrap to fail happened in the last
> 2 days.

No, it means that it happened between 2 and 3 days ago.

> Therefore, it is most likely that a change to one of the following is at
> fault:
>   lisp/international/code-pages.el
>   lisp/language/cyrillic.el
>   lisp/language/european.el
>   src/alloca.c
>   src/lisp.h
>   src/unexalpha.c
>   src/unexmacosx.c
>   src/w32.c
>   src/m/ia64.h

I would have thought it was obvious from the files that people have
reported they had success reverting that the following change is what
triggered the break in bootstrapping:

	* faces.el (face-set-after-frame-default): Ignore errors
	in face-spec-face-set.

	* cus-face.el (custom-declare-face): Add face-defface-spec
	prop after applying the face spec.


But it seems the real problem may be with a prior change to cl-macs.el

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Richard Stallman]

    I would have thought it was obvious from the files that people have
    reported they had success reverting that the following change is what
    triggered the break in bootstrapping:

	    * faces.el (face-set-after-frame-default): Ignore errors
	    in face-spec-face-set.

	    * cus-face.el (custom-declare-face): Add face-defface-spec
	    prop after applying the face spec.

I can't see anything in that change that might have caused either of
these files to need cl, or need anything they did not need before.
Can you?

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     I would have thought it was obvious from the files that people have
>     reported they had success reverting that the following change is what
>     triggered the break in bootstrapping:
> 
> 	    * faces.el (face-set-after-frame-default): Ignore errors
> 	    in face-spec-face-set.
> 
> 	    * cus-face.el (custom-declare-face): Add face-defface-spec
> 	    prop after applying the face spec.
> 
> I can't see anything in that change that might have caused either of
> these files to need cl, or need anything they did not need before.
> Can you?

I didn't look at the changes themselves in detail.  My thoughts were
based on a report that reverting faces.el and cus-face.el to the
previous version had made the problem go away. Maybe the person that
reported that had actually reverted more than just those two files,
so the report was bogus.

I don't see the report in the emacs-devel archives, so it probably
went to emacs-pretest-bug where Ben wouldn't have seen it.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Gord Peters]

I just tried to compile emacs on Mac OS X and I ran into the problem 
where "make bootstrap" fails with the following message:

. . .

Loading cus-face (source)...
Loading faces (source)...
Recursive `require' for feature `help-fns'
make[1]: *** [bootstrap-emacs] Error 255
make: *** [bootstrap] Error 2

I did a bit of digging and found that the change which causes the 
problem is in lisp/cus-face.el (between version 1.29 and 1.30).  I'm 
not sure why this causes the problem, or what the proper way to fix it 
is, but reverting back to version 1.29 of cus-face.el at least allowed 
me to compile successfully on Mac OS X.

	Gord

PS. I'm not subscribed to this list so if you have any responses, 
please CC me on them.

RE: make bootstrap fails with newest CVS sources - 2002-11-25

[Ben Key]

  > Reverting lisp/emacs-lisp/cl-macs.el to revision 1.34 (where cl-macs 
  > doesn't require help-fns) makes bootstrap proceed again.

I agree that reverting cl-macs.el to the earlier revision appears to resolve
the problem with make bootstrap.  However, the last time cl-macs.el was
changed was more than 8 weeks ago.  Up until last Thursday night I was doing
a make bootstrap on Emacs once or twice a day and everything worked fine.
Therefore I must conclude that the last change to cl-macs.el was not the one
that broke make bootstrap.  By reverting cl-macs.el we are only hiding the
problem, not solving it.  Something else changed in the last 5 days to break
make bootstrap.

At this time I do not have the time or the resources required to determine
what change really is the culprit, but I feel that it is important that we
make that determination.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Richard Stallman]

    Therefore I must conclude that the last change to cl-macs.el was not the one
    that broke make bootstrap.

You are probably right.

				By reverting cl-macs.el we are only hiding the
    problem, not solving it.

I disagree with that reasoning.  The problem is the cycle of requires,
and eliminating any one of them fixes it.

I think the argument that cl-macs.el should avoid requiring anything
is pretty strong.  After all, lots of files require cl-macs (via cl).
If cl-macs depends on anything, that will tend to lead to loops.

This does not mean we should not also change the code that made
button.el depend on cl-macs.  Maybe we do.  But why does it
depend on cl-macs?  It is not evident.  Can someone figure out why?
With A breakpoint at Frequire and a breakpoint at do_autoload you
can find it out easily.

RE: make bootstrap fails with newest CVS sources - 2002-11-25

[Ben Key]

    There appears to be a recursive load (I turned up the recursion check 
    from 2 to 3 in fns.c) to get it to fail in lread.
    
    Recursive load: "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
    "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
    "/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
    "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
    "/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
    "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
    "/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
    "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
    "/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
    "/dev/emacs/lisp/faces.el", "/dev/emacs/lisp/loadup.el"
    
    The chain appears to be cl-macs -> help-fns -> help-mode -> button -> 
    cl-macs

How did you get this information?  What did you have to change / enable in
order to get such a detailed report?  I spent quite some time searching for
a way to do something similar so I could provide more information when I
reported the problem, but I failed to find anything.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Steven Tamm]

In fns.c:Frequire I changed:

       if (nesting > 2)
	error ("Recursive `require' for feature `%s'",
	       SDATA (SYMBOL_NAME (feature)));

to:

       if (nesting > 3)
	error ("Recursive `require' for feature `%s'",
	       SDATA (SYMBOL_NAME (feature)));

This makes the recursive load die in lread.c:Fload (which produces the 
nicer error).  Fload fails if it tries to load the same file more than 
3 times.

I found this out totally by accident.  On darwin/Mac OS X, there is a 
problem with the apple-hacked GCC that it doesn't seem to export the 
structure definitions for Lisp_String and Lisp_Object because of the 
name conflict with the Lisp_Type enum.   So the gdb macros like xsymbol 
didn't work.   After I figured that out I just thought that the problem 
might go away if I allowed more nesting.  I was wrong.

BTW, To get the Lisp_String etc. structures to be loaded correctly into 
gdb on darwin all I did was add this to emacs.c

typedef Lisp_Object XLisp_Object;
typedef struct Lisp_String XLisp_String;
typedef struct Lisp_Symbol XLisp_Symbol;
typedef struct Lisp_Cons   XLisp_Cons;
XLisp_Object dummy1;
XLisp_String dummy2;
XLisp_Symbol dummy3;
XLisp_Cons dummy4;

Do any other platforms have the same problem, or is there some flag I 
can use to make this go away?
-Steven

On Tuesday, November 26, 2002, at 05:49  AM, Ben Key wrote:

>     There appears to be a recursive load (I turned up the recursion 
> check
>     from 2 to 3 in fns.c) to get it to fail in lread.
>
>     Recursive load: "/dev/emacs/lisp/emacs-lisp/cl-macs.el",
>     "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el",
>     "/dev/emacs/lisp/help-fns.el", 
> "/dev/emacs/lisp/emacs-lisp/cl-macs.el",
>     "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el",
>     "/dev/emacs/lisp/help-fns.el", 
> "/dev/emacs/lisp/emacs-lisp/cl-macs.el",
>     "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el",
>     "/dev/emacs/lisp/help-fns.el", 
> "/dev/emacs/lisp/emacs-lisp/cl-macs.el",
>     "/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el",
>     "/dev/emacs/lisp/help-fns.el", 
> "/dev/emacs/lisp/emacs-lisp/cl-macs.el",
>     "/dev/emacs/lisp/faces.el", "/dev/emacs/lisp/loadup.el"
>
>     The chain appears to be cl-macs -> help-fns -> help-mode -> button 
> ->
>     cl-macs
>
> How did you get this information?  What did you have to change / 
> enable in
> order to get such a detailed report?  I spent quite some time 
> searching for
> a way to do something similar so I could provide more information when 
> I
> reported the problem, but I failed to find anything.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Richard Stallman]

	   if (nesting > 3)
	    error ("Recursive `require' for feature `%s'",
		   SDATA (SYMBOL_NAME (feature)));

    This makes the recursive load die in lread.c:Fload (which produces the 
    nicer error).  Fload fails if it tries to load the same file more than 
    3 times.

Thanks.  Please do install it.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Steven Tamm]

On Wednesday, November 27, 2002, at 11:25  PM, Richard Stallman wrote:

> 	   if (nesting > 3)
> 	    error ("Recursive `require' for feature `%s'",
> 		   SDATA (SYMBOL_NAME (feature)));
>
>     This makes the recursive load die in lread.c:Fload (which produces 
> the
>     nicer error).  Fload fails if it tries to load the same file more 
> than
>     3 times.
>
> Thanks.  Please do install it.

Done.  Is the test for recursion in Frequire even necessary?  Would the 
testing in Fload suffice and the code dealing with recursion testing be 
removed? 

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Richard Stallman]

    Done.  Is the test for recursion in Frequire even necessary?  Would the 
    testing in Fload suffice and the code dealing with recursion testing be 
    removed? 

Maybe it isn't necessary, but why worry about the question?

make bootstrap fails with newest CVS sources - 2002-11-25

[Ben Key]

make bootstrap fails with newest CVS sources.  The error message is as
follows:

Recursive `require' for feature `help-fns'
NMAKE : fatal error U1077: '"d:\emacssrc\21.3\src/obj-spd/i386/temacs.exe"'
: return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual
Studio\VC98\bin\nmake.exe"' : return code '0x2'
Stop.

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Steven Tamm]

There appears to be a recursive load (I turned up the recursion check 
from 2 to 3 in fns.c) to get it to fail in lread.

Recursive load: "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
"/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
"/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
"/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
"/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
"/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
"/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
"/dev/emacs/lisp/button.el", "/dev/emacs/lisp/help-mode.el", 
"/dev/emacs/lisp/help-fns.el", "/dev/emacs/lisp/emacs-lisp/cl-macs.el", 
"/dev/emacs/lisp/faces.el", "/dev/emacs/lisp/loadup.el"

The chain appears to be cl-macs -> help-fns -> help-mode -> button -> 
cl-macs

Reverting lisp/emacs-lisp/cl-macs.el to revision 1.34 (where cl-macs 
doesn't require help-fns) makes bootstrap proceed again.
The only thing I don't really understand is why button.el requires 
cl-macs?

-Steven

On Monday, November 25, 2002, at 09:29  AM, Ben Key wrote:

> make bootstrap fails with newest CVS sources.  The error message is as
> follows:
>
> Recursive `require' for feature `help-fns'
> NMAKE : fatal error U1077: 
> '"d:\emacssrc\21.3\src/obj-spd/i386/temacs.exe"'
> : return code '0xffffffff'
> Stop.
> NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual
> Studio\VC98\bin\nmake.exe"' : return code '0x2'
> Stop.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Miles Bader]

Steven Tamm <steventamm@mac.com> writes:
> Reverting lisp/emacs-lisp/cl-macs.el to revision 1.34 (where cl-macs 
> doesn't require help-fns) makes bootstrap proceed again.
> The only thing I don't really understand is why button.el requires 
> cl-macs?

It shouldn't, but who knows, the cl stuff tends to creep...

I think having cl-macs require anything is also bad, though, since it
itself tends to get loaded at odd times during compilation.

-Miles
-- 
We live, as we dream -- alone....

Re: make bootstrap fails with newest CVS sources - 2002-11-25

[Richard Stallman]

    Reverting lisp/emacs-lisp/cl-macs.el to revision 1.34 (where cl-macs 
    doesn't require help-fns) makes bootstrap proceed again.
    The only thing I don't really understand is why button.el requires 
    cl-macs?

It is easy to find this out with a breakpoint at Frequire
and another at do_autoload.

We should change button.el not to use cl-macs at all.