make bootstrap fails.

make bootstrap fails.

[Steven T. Hatton]

I finally figured out that I need to checkout the cvs archive to a host with a 
public IP address (or change some, to me, unknown configuration).  Now that I 
have the source, I'm having a hard time getting it to bootstrap.  

`make' results in the following message:

Your tree does not include the compiled Lisp files.
You need to do `make bootstrap' to build Emacs.
Emacs now requires Texinfo version 4.2.
make: *** [maybe_bootstrap] Error 1

`make bootstrap' results in:

(cd src;      make  mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[1]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[2]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[3]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[4]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
/bin/sh: line 1: cd: src: No such file or directory
make[5]: Entering directory `/download/org/gnu/emacs'
(cd src;      make -w mostlyclean)
... Ad infinitum (almost)

Suggestions?

STH

Re: make bootstrap fails.

[Luc Teirlinck]

Steven T. Hatton wrote:

   Now that I have the source, I'm having a hard time getting it to
   bootstrap.

There are instructions in emacs/INSTALL.CVS.

Basically:

cd emacs
./configure
make bootstrap
make install

(Assuming that you have Texinfo version 4.2 or later.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 19:44, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    Now that I have the source, I'm having a hard time getting it to
>    bootstrap.
>
> There are instructions in emacs/INSTALL.CVS.
>
> Basically:
>
> cd emacs
> ./configure
> make bootstrap
> make install
>
> (Assuming that you have Texinfo version 4.2 or later.)
>
> Sincerely,
>
> Luc.

I should have mentioned that I had done the `./configure' prior to the 'make 
bootstrap'.  Following the above procedure results in the failure described. 
This is a SuSE 9.0 box.  

STH

Re: make bootstrap fails. env problem

[Steven T. Hatton]

On Friday 30 January 2004 19:54, Steven T. Hatton wrote:
> On Friday 30 January 2004 19:44, Luc Teirlinck wrote:

> I should have mentioned that I had done the `./configure' prior to the
> 'make bootstrap'.  Following the above procedure results in the failure
> described. This is a SuSE 9.0 box.
>
> STH

It looks to be in my user environment, but I'm not sure what is causing the 
problem.  Under a different login I am able to build.  Perhaps it smells my 
xemacs?  Rather strange, because I removed everything from $PATH but /bin 
and /usr/bin.  There's nothing but mozilla nss and nspr libs in the 
LD_LIBRARY_PATH.  

STH

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 19:44, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    Now that I have the source, I'm having a hard time getting it to
>    bootstrap.
>
> There are instructions in emacs/INSTALL.CVS.
>
> Basically:
>
> cd emacs
> ./configure
> make bootstrap
> make install
>
> (Assuming that you have Texinfo version 4.2 or later.)
>
> Sincerely,
>
> Luc.

I should have mentioned that I had done the `./configure' prior to the 'make 
bootstrap'.  Following the above procedure results in the failure described. 
This is a SuSE 9.0 box.  

STH

Re: make bootstrap fails.

[Luc Teirlinck]

Steven T. Hatton wrote:

   I should have mentioned that I had done the `./configure' prior to
   the 'make bootstrap'.  Following the above procedure results in the
   failure described.  This is a SuSE 9.0 box.

I do not understand then.  If you checked out the CVS correctly, you
should have an emacs/src directory, even though the error messsages
seem to claim you do not.  Do you get an error if you just do `cd src'
instead of `make bootstrap'?

Sincerely,

Luc.

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 20:48, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    I should have mentioned that I had done the `./configure' prior to
>    the 'make bootstrap'.  Following the above procedure results in the
>    failure described.  This is a SuSE 9.0 box.
>
> I do not understand then.  If you checked out the CVS correctly, you
> should have an emacs/src directory, even though the error messsages
> seem to claim you do not.  Do you get an error if you just do `cd src'
> instead of `make bootstrap'?
>
> Sincerely,
>
> Luc.
>

I built as root, and it built and installed without a problem. I also built 
under a different user without a problem. I also discovered I couldn't run 
make even with a bootstrapped source tree in my normal user environment. If I 
gain insight into this, I will be sure and share.  Right now, I must move 
one.

I will add, Emacs launches much more quickly than the stale build I've been 
using. 

STH

Re: make bootstrap fails.

[Steven T. Hatton]

On Friday 30 January 2004 20:48, Luc Teirlinck wrote:
> Steven T. Hatton wrote:
>
>    I should have mentioned that I had done the `./configure' prior to
>    the 'make bootstrap'.  Following the above procedure results in the
>    failure described.  This is a SuSE 9.0 box.
>
> I do not understand then.  If you checked out the CVS correctly, you
> should have an emacs/src directory, even though the error messsages
> seem to claim you do not.  Do you get an error if you just do `cd src'
> instead of `make bootstrap'?
>
> Sincerely,
>
> Luc.

I figured it out.  I recently added a CDPATH to my .bashrc. I had the feeling 
when I did it, I would regret having done so.  unset CDPATH. Problem solved.

STH

Re: make bootstrap fails.

[Richard Stallman]

    I figured it out.  I recently added a CDPATH to my .bashrc. I had the feeling 
    when I did it, I would regret having done so.  unset CDPATH. Problem solved.

I am surprised that having a CDPATH causes a problem.  If you can
determine where in the Makefile it makes a difference, we can probably
fix it easily.

Re: make bootstrap fails.

[Kai Grossjohann]

"Steven T. Hatton" <hattons@speakeasy.net> writes:

> (cd src;      make  mostlyclean)
> /bin/sh: line 1: cd: src: No such file or directory

cd fails.  So maybe it's $CDPATH or something like this?

Kai

Re: make bootstrap fails.

[Kim F. Storm]

Kai Grossjohann <kai@emptydomain.de> writes:

> "Steven T. Hatton" <hattons@speakeasy.net> writes:
> 
> > (cd src;      make  mostlyclean)
> > /bin/sh: line 1: cd: src: No such file or directory
> 
> cd fails.  So maybe it's $CDPATH or something like this?

Maybe using cd ./src is safer ?

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

Re: make bootstrap fails.

[Luc Teirlinck]

Kim Storm wrote:

   Kai Grossjohann <kai@emptydomain.de> writes:

   > "Steven T. Hatton" <hattons@speakeasy.net> writes:
   > 
   > > (cd src;      make  mostlyclean)
   > > /bin/sh: line 1: cd: src: No such file or directory
   > 
   > cd fails.  So maybe it's $CDPATH or something like this?

   Maybe using cd ./src is safer ?

Except that src is not the only problem.  There are plenty of relative
names used all over Makefile.in.  I am not an expert in Makefiles, but
would the logical thing not be to execute stuff in a subshell, and
either set CDPATH to the appropriate value or unset it?  Makefile.in
already seems to do the latter at several places, but maybe there are
some inadvertent omissions.

Sincerely,

Luc.

Re: make bootstrap fails.

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Except that src is not the only problem.  There are plenty of relative
> names used all over Makefile.in.  I am not an expert in Makefiles, but
> would the logical thing not be to execute stuff in a subshell, and
> either set CDPATH to the appropriate value or unset it?  Makefile.in
> already seems to do the latter at several places, but maybe there are
> some inadvertent omissions.

Before making big changes like this, let's check with the OP whether
this is really the problem.  Just my two cents.

Kai

Re: make bootstrap fails.

[Luc Teirlinck]

Kai Grossjohann wrote:

   Before making big changes like this, let's check with the OP whether
   this is really the problem.  Just my two cents.

I do not know whether this is the problem in the case of the OP.  It
is definitely a fact though that if CDPATH is set and does not start
with a colon, problems can develop.

I did:

export CDPATH=~/  (admittedly stupid CDPATH, but still.)
./configure --without-toolkit-scroll-bars
make bootstrap

Result:

[bash2.05b.0 ~/emacscvsdir/emacs 3 11] make bootstrap
(cd src;      make  mostlyclean)
/home/teirllm/src
make[1]: Entering directory `/home/teirllm/src'
make[1]: *** No rule to make target `mostlyclean'.  Stop.
make[1]: Leaving directory `/home/teirllm/src'
make: *** [bootstrap-clean-before] Error 2

The question of whether a change in Makefile.in is necessary is
equivalent to the question of whether the Makefile should support
values of CDPATH not starting with a colon.  (If CDPATH starts with a
colon, there should be no problem.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Richard Stallman]

    I do not know whether this is the problem in the case of the OP.  It
    is definitely a fact though that if CDPATH is set and does not start
    with a colon, problems can develop.

If it is not easy to fix this problem, please don't worry about it too
much.  It would be worth a small effort, but not a large one.

Re: make bootstrap fails.

[Luc Teirlinck]

Richard Stallman wrote:

       I do not know whether this is the problem in the case of the OP.  It
       is definitely a fact though that if CDPATH is set and does not start
       with a colon, problems can develop.

   If it is not easy to fix this problem, please don't worry about it too
   much.  It would be worth a small effort, but not a large one.

I set CDPATH in my shell to ~/, a highly inappropriate value for
emacs/Makefile.in and did:

make distclean
./configure --without-toolkit-scroll-bars
make bootstrap
sudo make install

without any problems after applying the trivial patch below.

A caveat is in order though.  I am not an expert on Makefile.in.
If Makefile.in for some strange reason needs to access the user's
CDPATH, then I am suggesting something dangerous, even though it works
perfectly for me.  (I usually do not have CDPATH set.)  This seems
excessively unlikely to me.

===File ~/Makefile.in-diff==================================
*** Makefile.in.~1.284.~	Mon Feb  2 16:31:15 2004
--- Makefile.in	Tue Feb  3 10:35:22 2004
***************
*** 53,58 ****
--- 53,60 ----
  
  SHELL = /bin/sh
  
+ CDPATH=
+ 
  # If Make doesn't predefine MAKE, set it here.
  @SET_MAKE@
  
============================================================

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> without any problems after applying the trivial patch below.

I'm not sure, but some versions of make might require that you
(somehow) export the CDPATH variable to the environment, but
I don't remember the details.  

In any case, unsetting CDPATH like this cannot do any harm!

> 
> A caveat is in order though.  I am not an expert on Makefile.in.
> If Makefile.in for some strange reason needs to access the user's
> CDPATH, 

.. then I would say that Makefile.in has a bug, so there's no reason
to consider that possibility, IMO.


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

Re: make bootstrap fails.

[Luc Teirlinck]

Kim Storm wrote:

   I'm not sure, but some versions of make might require that you
   (somehow) export the CDPATH variable to the environment, but
   I don't remember the details.  

You mean that for certain versions of make one should use
`export CDPATH=' instead of just `CDPATH='?

The `make' manual seems to say that variables exported to make from
the environment are automatically exported to sub-make's anyway and,
moreover, at first view it would seem to not make any difference
whether CDPATH is the empty string or not defined at all.

Or do some versions of make actually reinitialize environment
variables directly from the shell environment that invoked make for
sub-make's if not exported?

Anyway, it would seem like the `export' can not do any harm, even
though I do not immediately understand how it could do some good.
(But I know very little about Makefiles).

Sincerely,

Luc.

Re: make bootstrap fails.

[Jan D.]

> Or do some versions of make actually reinitialize environment
> variables directly from the shell environment that invoked make for
> sub-make's if not exported?

At least clearmake (from clearcase) does not export variables by 
default.
I don't know if there is a need to reinitialize the environment,
make variables and environment variables are just kept separate.

	Jan D.

Re: make bootstrap fails.

[Luc Teirlinck]

There would seem to be four possibilities:

1.  CDPATH=

2.  export CDPATH=

3.  use the shell command `unset CDPATH' at various places all over
    Makefile.in. 

4.  systematically do `cd ./dir' rather than `cd dir' at every single
    occurrence of cd in all Makefiles.  That includes the case where
    dir is a variable expanding to a relative name.

Clearly, 3 and 4 require both some initial work and carefulness when
subsequently making changes to the Makefile.  So I believe they should
only be considered if we agreed that both 1 and 2 are too simplistic.
Note also that, even without any change, problems only develop with a
user CDPATH _not starting with a colon_.  Personally, I would not want
to be using such a CDPATH and certainly not export it, because it
seems like a dangerous thing to do.  Richard has already stated that
he does not believe that the problem is worth a substantial amount of
work.

There are currently no instances of use of the make `export' directive
in Makefile.in.  Maybe it was avoided because some make's do not
understand it.  Hence I am afraid that (2) might break some make's
even if CDPATH is unset.  Maybe somebody can assure me that this fear
is groundless.

(1) definitely seems to work for GNU make and might work for other
makes, maybe even all makes.  Importantly, it will not make the
situation _worse_ for _any_ make.  On the other hand (3) is used at
some (but not enough) places in Makefile.in already, so maybe (1)
will not solve the problem for _all_ makes.

What if I just go ahead and install my trivial "CDPATH=" change, which
as already said, at least will do no harm and at least some good?
Then we can always decide what to do if problems persist for some non
GNU make's, say maybe clearmake.  (Maybe add `export' or maybe go for
(3).)

People with possibly problematic make's can always experiment by
making directories, say ~/cdpath and ~/cdpath/src and doing `export
CDPATH=~/cdpath" before bootstrapping or using other instances of
make.  (Of course, do not forget to set CDPATH back afterwards.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> There would seem to be four possibilities:

I agree with your analysis.


> 
> 1.  CDPATH=

IMO, this is sufficient, possibly with a note in PROBLEMS that make
may fail with some non-gnu versions of make if the user has a CDPATH
which doesn't include the current directory.

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

Re: make bootstrap fails.

[Luc Teirlinck]

There is also the question of whether other make's _automatically_ unset
CDPATH.  GNU make does not.  I took a look at some other Makefiles and
it would seem that a value of CDPATH not starting with a colon would
derail _most_ Makefiles, because they use cd with relative names and
apparently do not seem to do any effort to protect themselves from
CDPATH.  Just a long shot: could not unsetting CDPATH automatically be
considered a bug in GNU make?

Sincerely,

Luc.

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Or do some versions of make actually reinitialize environment
> variables directly from the shell environment that invoked make for
> sub-make's if not exported?

I don't know -- that's why I asked...

> 
> Anyway, it would seem like the `export' can not do any harm, even
> though I do not immediately understand how it could do some good.
> (But I know very little about Makefiles).

Unless there are version of make which doesn't understand "export".

If it works in your setup without export, I suggest we don't use it.

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

Re: make bootstrap fails.

[Luc Teirlinck]

Kai Grossjohann wrote:

   Before making big changes like this, let's check with the OP whether
   this is really the problem.

Actuallly, what is strange in the case of the OP is that he got an
error message saying that src did not exist.  That is strange, because
at least the version of bash I am using (bash2.05b.0) always
_implicitly_ adds a colon at the _end_ of CDPATH by trying out the
current directory if nothing else worked.  That is, you can wind up in
the wrong src, as in the example I gave, but otherwise ./src should
be found.  Maybe CDPATH caused the OP to start bootstrapping in the
wrong "emacs" directory to begin with.

Sincerely,

Luc.

Re: make bootstrap fails.

[Kai Grossjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Actuallly, what is strange in the case of the OP is that he got an
> error message saying that src did not exist.  That is strange, because
> at least the version of bash I am using (bash2.05b.0) always
> _implicitly_ adds a colon at the _end_ of CDPATH by trying out the
> current directory if nothing else worked.

Does the OP use bash?

Kai

Re: make bootstrap fails.

[Luc Teirlinck]

Kai Grossjohann wrote:

   Luc Teirlinck <teirllm@dms.auburn.edu> writes:

   > Actuallly, what is strange in the case of the OP is that he got an
   > error message saying that src did not exist.  That is strange, because
   > at least the version of bash I am using (bash2.05b.0) always
   > _implicitly_ adds a colon at the _end_ of CDPATH by trying out the
   > current directory if nothing else worked.

   Does the OP use bash?

   Kai

I should have checked better.  When bash is invoked as sh, it indeed
does not check ./ if nothing else worked.  With CDPATH=~/src, I get
the same errors as the OP when doing make bootstrap.  The Makefile
uses /bin/sh.  (Which shell the user uses is irrelevant, because bash
does not _really_ add a colon to the end of CDPATH.  It just gets the
same behavior by checking the current directory if nothing else worked.)

Sincerely,

Luc.

Re: make bootstrap fails.

[Stefan Monnier]

> I should have checked better.  When bash is invoked as sh, it indeed
> does not check ./ if nothing else worked.  With CDPATH=~/src, I get
> the same errors as the OP when doing make bootstrap.  The Makefile
> uses /bin/sh.

The SUSv3 does not list CDPATH as a variable that might affect the behavior
of /bin/sh, so I think it should be considered as a bug in bash (we'll
still need to work around it, but it should be reported to the bash
maintainers and/or to the distributions that use bash as /bin/sh).

Of course, someone should check that bash invoked as /bin/sh indeed
mistakenly obeys an inherited CDPATH envvar, but the reports here lead me
to believe this is the case.


        Stefan

Re: make bootstrap fails.

[Luc Teirlinck]

Stefan Monnier wrote:

   The SUSv3 does not list CDPATH as a variable that might affect the behavior
   of /bin/sh, so I think it should be considered as a bug in bash (we'll
   still need to work around it, but it should be reported to the bash
   maintainers and/or to the distributions that use bash as /bin/sh).

   Of course, someone should check that bash invoked as /bin/sh indeed
   mistakenly obeys an inherited CDPATH envvar, but the reports here lead me
   to believe this is the case.

I could give actual examples of bash invoked as sh obeying an
inherited CDPATH, but let me first make sure that I understand you.
Are you saying that sh should completely ignore CDPATH?  That would be
strange, because, for instance, the Solaris 8 version of sh treats
CDPATH exactly like Bash invoked as sh does, and `(bash)Bourne Shell
Variables' explicitly lists CDPATH as a variable taken over from the
Bourne shell.  Moreover, other Makefiles, for instance the texinfo-4.6
Makefile use their own CDPATH (they do not just unset CDPATH) even
though they use /bin/sh.

Sincerely,

Luc.

Re: make bootstrap fails.

[Stefan Monnier]

> I could give actual examples of bash invoked as sh obeying an
> inherited CDPATH, but let me first make sure that I understand you.
> Are you saying that sh should completely ignore CDPATH?  That would be

Well, after further reading, CDPATH is not mentioned in `sh' but is
mentioned in `cd'.  So, I guess I was wrong, and to be protected from
CDPATH, we should always use ./foo rather than foo.

Too bad: CDPATH really feels like an interactive-only feature.


        Stefan

Re: make bootstrap fails.

[Luc Teirlinck]

Stefan Monnier wrote:

   So, I guess I was wrong, and to be protected from
   CDPATH, we should always use ./foo rather than foo.

   Too bad: CDPATH really feels like an interactive-only feature.

What is wrong with just unsetting CDPATH?  As the Makefile runs in a
subshell, it will not mess up the user's environment.

Sincerely,

Luc.

Re: make bootstrap fails.

[Luc Teirlinck]

>From my earlier reply:
   
   Moreover, other Makefiles, for instance the texinfo-4.6
   Makefile use their own CDPATH (they do not just unset CDPATH) even
   though they use /bin/sh.

I said something inaccurate here: it locally sets CDPATH for one
particular command (am_cd).  But the point remains the same.  That
command is executed by /bin/sh.

Sincerely,

Luc.

Re: make bootstrap fails.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
> 
>    Kai Grossjohann <kai@emptydomain.de> writes:
> 
>    > "Steven T. Hatton" <hattons@speakeasy.net> writes:
>    > 
>    > > (cd src;      make  mostlyclean)
>    > > /bin/sh: line 1: cd: src: No such file or directory
>    > 
>    > cd fails.  So maybe it's $CDPATH or something like this?
> 
>    Maybe using cd ./src is safer ?
> 
> Except that src is not the only problem.  There are plenty of relative
> names used all over Makefile.in.  I am not an expert in Makefiles, but
> would the logical thing not be to execute stuff in a subshell, and
> either set CDPATH to the appropriate value or unset it?  Makefile.in
> already seems to do the latter at several places, but maybe there are
> some inadvertent omissions.

Things are executed in a subshell, so I guess the Makefile should
be able to unset CDPATH in the environment at the global level.

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

Re: make bootstrap fails.

[Luc Teirlinck]

Kim Storm wrote:

   Things are executed in a subshell, so I guess the Makefile should
   be able to unset CDPATH in the environment at the global level.

Yes, unless the Makefile would for some strange reason need to use the
user defined value of CDPATH, at one place or another, which seems
excessively unlikely.

Sincerely,

Luc.

Re: make bootstrap fails

[Stefan Monnier]

> Making generated-autoload-file local to  *autoload-file* while let-bound!
> Generating autoloads for dired-aux.el...
> Error: (error "Running bzr status --no-classify dired.el...FAILED (status 4)")
> Running bzr status --no-classify dired.el...FAILED (status 4)

Please report it as a bug.  It might be triggered by a problematic
installation of Bzr or something else, but Emacs's build should not fail
just because it can't determine the VC status of a file.


        Stefan

Re: make bootstrap fails

[Glenn Morris]

Stefan Monnier wrote:

>> Running bzr status --no-classify dired.el...FAILED (status 4)
>
> Please report it as a bug.  It might be triggered by a problematic
> installation of Bzr or something else, but Emacs's build should not fail
> just because it can't determine the VC status of a file.

The simple solution is just to disable all vc backends while building
(not like they can do anything at all except cause a slow-down), as
previously suggested:

http://lists.gnu.org/archive/html/emacs-devel/2010-08/msg00461.html

However there was some opposition to the idea.

Re: make bootstrap fails

[Stefan Monnier]

>>> Running bzr status --no-classify dired.el...FAILED (status 4)
>> 
>> Please report it as a bug.  It might be triggered by a problematic
>> installation of Bzr or something else, but Emacs's build should not fail
>> just because it can't determine the VC status of a file.

> The simple solution is just to disable all vc backends while building
> (not like they can do anything at all except cause a slow-down), as
> previously suggested:

> http://lists.gnu.org/archive/html/emacs-devel/2010-08/msg00461.html

> However there was some opposition to the idea.

As explained back then: if it's a problem while building Emacs, there's
no reason to think it won't be a problem in other use cases.  So it
should be fixed the right way, rather than swept under the carpet.


        Stefan

Re: make bootstrap fails

[Glenn Morris]

Stefan Monnier wrote:

> As explained back then: if it's a problem while building Emacs, there's
> no reason to think it won't be a problem in other use cases.  So it
> should be fixed the right way, rather than swept under the carpet.

So if I fix this bug, and add something to test/automated/vc.bzr.el to
prevent it coming back, may I then turn off vc during the Emacs build?

Re: make bootstrap fails

[Stefan Monnier]

>> As explained back then: if it's a problem while building Emacs, there's
>> no reason to think it won't be a problem in other use cases.  So it
>> should be fixed the right way, rather than swept under the carpet.
> So if I fix this bug, and add something to test/automated/vc.bzr.el to
> prevent it coming back, may I then turn off vc during the Emacs build?

No, because it might hide other bugs.  We want to eat our own dog-food.


        Stefan

Re: make bootstrap fails

[Glenn Morris]

Stefan Monnier wrote:

>> So if I fix this bug, and add something to test/automated/vc.bzr.el to
>> prevent it coming back, may I then turn off vc during the Emacs build?
>
> No, because it might hide other bugs.  We want to eat our own dog-food.

IMO, it's making people who want to build Emacs eat dog food.

We should write more VC test cases, rather than forcing people who just
want to build the thing to test it for us. I've added one for this case,
and fixed it.

Re: make bootstrap fails

[Chris Van Dusen]

On Apr 10, 2012, at 10:24 PM, Glenn Morris wrote:

>> No, because it might hide other bugs.  We want to eat our own dog-food.
> 
> IMO, it's making people who want to build Emacs eat dog food.
> 
> We should write more VC test cases, rather than forcing people who just
> want to build the thing to test it for us. I've added one for this case,
> and fixed it.
> 

I can understand (and agree with) a dog food eating policy, but it seems 
like it would be in a test, not the actual build.

Regardless, I was able to build it. Thanks!

arf.

make bootstrap fails

[Chris Van Dusen]

Hi,

I checked out Emacs from bzr yesterday, and was trying to build it, but received the error below after performing the following steps:

$ sh autogen.sh
$ ./configure --with-ns
$ make bootstrap
.
.
.
Generating autoloads for desktop.el...
Generating autoloads for desktop.el...done
Generating autoloads for dframe.el...
Generating autoloads for dframe.el...done
Making generated-autoload-file local to  *autoload-file* while let-bound!
Generating autoloads for dired-aux.el...
Error: (error "Running bzr status --no-classify dired.el...FAILED (status 4)")
Running bzr status --no-classify dired.el...FAILED (status 4)
make[3]: *** [autoloads] Error 255
make[2]: *** [/Users/chrisvandusen/src/emacs/src/../lisp/loaddefs.el] Error 2
make[1]: *** [src] Error 2
make: *** [bootstrap] Error 2

This is on Mac OS 10.6.8.

Does anyone have any ideas about what might be causing this?  If there is more info needed, just let me know.


Thanks,
Chris.

Re: make bootstrap fails

[Kuroishi Mitsuo]

  Message-id: <1E9920B1-E2BD-4B07-A027-3777FDEFD6D7@gmail.com>
  From:       Chris Van Dusen <cavandusen@gmail.com>
  Subject:    make bootstrap fails
  Date:       Sun, 8 Apr 2012 18:46:01 -0500

  > $ sh autogen.sh
  > $ ./configure --with-ns
  > $ make bootstrap
  > .
  > .
  > .
  > Generating autoloads for desktop.el...
  > Generating autoloads for desktop.el...done
  > Generating autoloads for dframe.el...
  > Generating autoloads for dframe.el...done
  > Making generated-autoload-file local to  *autoload-file* while let-bound!
  > Generating autoloads for dired-aux.el...
  > Error: (error "Running bzr status --no-classify dired.el...FAILED (status 4)")
  > Running bzr status --no-classify dired.el...FAILED (status 4)
  > make[3]: *** [autoloads] Error 255
  > make[2]: *** [/Users/chrisvandusen/src/emacs/src/../lisp/loaddefs.el] Error 2
  > make[1]: *** [src] Error 2
  > make: *** [bootstrap] Error 2
  > 
  > This is on Mac OS 10.6.8.
  > 
  > Does anyone have any ideas about what might be causing this?
    If there is more info needed, just let me know.

I had the same problem above the other day.

In my case the bzr command didn't work properly because I
install Python under ~/local and I needed to set PYTHONPATH
correctly.

I guess your bzr executed from the make command doesn't work
well. Why don't you check about it.

For your convenience.

Regards,

--
Kuroishi Mitsuo

Re: make bootstrap fails

[Eli Zaretskii]

> From: Chris Van Dusen <cavandusen@gmail.com>
> Date: Sun, 8 Apr 2012 18:46:01 -0500
> 
> I checked out Emacs from bzr yesterday, and was trying to build it, but received the error below after performing the following steps:
> 
> $ sh autogen.sh
> $ ./configure --with-ns
> $ make bootstrap
> .
> .
> .
> Generating autoloads for desktop.el...
> Generating autoloads for desktop.el...done
> Generating autoloads for dframe.el...
> Generating autoloads for dframe.el...done
> Making generated-autoload-file local to  *autoload-file* while let-bound!
> Generating autoloads for dired-aux.el...
> Error: (error "Running bzr status --no-classify dired.el...FAILED (status 4)")
> Running bzr status --no-classify dired.el...FAILED (status 4)

What happens if you go to the lisp directory and type this at the
shell prompt:

 bzr status --no-classify dired.el

Re: make bootstrap fails

[Chris Van Dusen]

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

On Mon, Apr 9, 2012 at 1:52 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Chris Van Dusen <cavandusen@gmail.com>
> > Date: Sun, 8 Apr 2012 18:46:01 -0500
> >
> > I checked out Emacs from bzr yesterday, and was trying to build it, but
> received the error below after performing the following steps:
> >
> > $ sh autogen.sh
> > $ ./configure --with-ns
> > $ make bootstrap
> > .
> > .
> > .
> > Generating autoloads for desktop.el...
> > Generating autoloads for desktop.el...done
> > Generating autoloads for dframe.el...
> > Generating autoloads for dframe.el...done
> > Making generated-autoload-file local to  *autoload-file* while let-bound!
> > Generating autoloads for dired-aux.el...
> > Error: (error "Running bzr status --no-classify dired.el...FAILED
> (status 4)")
> > Running bzr status --no-classify dired.el...FAILED (status 4)
>
> What happens if you go to the lisp directory and type this at the
> shell prompt:
>
>  bzr status --no-classify dired.el
>
>
Interesting.  Here's the output:

~/src/emacs/lisp$ bzr status --no-classify dired.el
bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument
'no_classify'

Traceback (most recent call last):
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 946, in
exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 1150,
in run_bzr
    ret = run(*run_argv)
  File "/Library/Python/2.6/site-packages/bzrlib/plugins/loom/commands.py",
line 203, in run_argv_aliases
    super(cmd_status, self).run_argv_aliases(list(argv), alias_argv)
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 699, in
run_argv_aliases
    return self.run(**all_cmd_args)
  File "/Library/Python/2.6/site-packages/bzrlib/commands.py", line 721, in
run
    return self._operation.run_simple(*args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/cleanup.py", line 135, in
run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/Library/Python/2.6/site-packages/bzrlib/cleanup.py", line 165, in
_do_with_cleanups
    result = func(*args, **kwargs)
TypeError: run() got an unexpected keyword argument 'no_classify'

bzr 2.4.2 on python 2.6.1 (Darwin-10.8.0-i386-64bit)
arguments: ['/usr/local/bin/bzr', 'status', '--no-classify', 'dired.el']
plugins: bash_completion[2.4.2], bzrtools[2.4.0], changelog_merge[2.4.2],
    colo[0.3.0], email[unknown], explorer[1.2.1], extmerge[unknown],
    fastimport[0.11.0dev], keychain[0.1.0], launchpad[2.4.2],
loom[2.2.1dev],
    netrc_credential_store[2.4.2], news_merge[2.4.2], pipeline[1.1.0],
    qbzr[0.22.0dev], rewrite[0.6.2], svn[1.1.0], upload[1.0.1dev],
    weave_fmt[2.4.2], xmloutput[0.8.7]
encoding: 'UTF-8', fsenc: 'utf-8', lang: 'en_US.UTF-8'

*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.  You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

[-- Attachment #2: Type: text/html, Size: 4134 bytes --]

Re: make bootstrap fails

[Eli Zaretskii]

> Date: Mon, 9 Apr 2012 08:49:42 -0500
> From: Chris Van Dusen <cavandusen@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
> > What happens if you go to the lisp directory and type this at the
> > shell prompt:
> >
> >  bzr status --no-classify dired.el
> >
> >
> Interesting.  Here's the output:
> 
> ~/src/emacs/lisp$ bzr status --no-classify dired.el
> bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument
> 'no_classify'

Looks like your bzr installation is broken.  (And why do you have
bzrlib in site-packages? perhaps it's an incompatible version of
bzrlib?)

Re: make bootstrap fails

[cavd]

On Apr 9, 2012, at 10:47, Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Mon, 9 Apr 2012 08:49:42 -0500
>> From: Chris Van Dusen <cavandusen@gmail.com>
>> Cc: help-gnu-emacs@gnu.org
>> 
>>> What happens if you go to the lisp directory and type this at the
>>> shell prompt:
>>> 
>>> bzr status --no-classify dired.el
>>> 
>>> 
>> Interesting.  Here's the output:
>> 
>> ~/src/emacs/lisp$ bzr status --no-classify dired.el
>> bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument
>> 'no_classify'
> 
> Looks like your bzr installation is broken.  (And why do you have
> bzrlib in site-packages? perhaps it's an incompatible version of
> bzrlib?)
> 

I'm not sure about bzrlib. I'm using the bzr bundle for 10.6., and it's the latest stable version. 

I'll look closer at the bzr aspect, and report back. 

Thanks,
Chris

make bootstrap fails

[Emacs-Hacker]

The latest CVS version of emacs fails to build on MacOS 10.4.2 (the problem might not be OS X specific, though).

Full transcript at

	http://jovi.net/emacs-make-bootstrap-failure.wall

$ cvs update -P -d
$ make distclean
$ ./configure --enable-carbon-app --without-x
$ make bootstrap
...
gcc  -prebind -framework Carbon -framework QuickTime -Xlinker -headerpad -Xlinker 690  -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o  window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o   emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexmacosx.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o  mac.o macterm.o macfns.o macmenu.o macselect.o fontset.o fringe.o image.o  terminfo.o lastfile.o         -lncurses   
ld: warning multiple definitions of symbol _PC
terminfo.o definition of _PC in section (__DATA,__common)
/usr/lib/libncurses.dylib(lib_tputs.o) definition of _PC
ld: warning multiple definitions of symbol _UP
terminfo.o definition of _UP in section (__DATA,__common)
/usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP
ld: warning multiple definitions of symbol _BC
terminfo.o definition of _BC in section (__DATA,__common)
/usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC
ld: /usr/lib/crt1.o illegal reference to symbol: __objcInit defined in indirectly referenced dynamic library /usr/lib/libobjc.A.dylib
make[1]: *** [temacs] Error 1
make: *** [bootstrap-build] Error 2

		Peace
			--Devon
	 /~\
	 \ /	Health Care
	  X 	not warfare
	 / \

	Dubya won the digital vote
	Kerry won the popular vote

PS: This exact symptom has troubled us before...

	http://lists.gnu.org/archive/html/emacs-devel/2003-02/msg00355.html

From:	Mark Moll
Subject: make bootstrap fails
Date:	Thu, 13 Feb 2003 17:03:05 -0600

make (bootstrap) fails

[Lennart Borgman]

CVS from today:

D:\ecvs\bld\emacs\nt>make
Using D:\WINNT\system32\cmd.exe as shell.
.
.
make  -C ../lib-src all
make[1]: *** No rule to make target `getopt.h', needed by 
`oo-spd/i386/ctags.o'.  Stop.
make[1]: Entering directory `D:/ecvs/bld/emacs/lib-src'
make[1]: Leaving directory `D:/ecvs/bld/emacs/lib-src'
make: *** [all-other-dirs-gmake] Error 2

Re: make (bootstrap) fails

[Lennart Borgman]

Lennart Borgman wrote:

> CVS from today:
>
> D:\ecvs\bld\emacs\nt>make
> Using D:\WINNT\system32\cmd.exe as shell.
> .
> .
> make  -C ../lib-src all
> make[1]: *** No rule to make target `getopt.h', needed by 
> `oo-spd/i386/ctags.o'.  Stop.
> make[1]: Entering directory `D:/ecvs/bld/emacs/lib-src'
> make[1]: Leaving directory `D:/ecvs/bld/emacs/lib-src'
> make: *** [all-other-dirs-gmake] Error 2
>
More info: It looks like it is only broken on w32 (but I am not sure 
since I only have w32 here).

Re: make (bootstrap) fails

[Juanma Barranquero]

On 7/27/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> Lennart Borgman wrote:

For the moment being, copy lib-src/getopt_.h to lib-src/getopt.h and
it should build.

-- 
                    /L/e/k/t/u

Re: make (bootstrap) fails

[Lennart Borgman]

Juanma Barranquero wrote:

>For the moment being, copy lib-src/getopt_.h to lib-src/getopt.h and
>it should build.
>  
>
Thanks, that worked.

Re: make (bootstrap) fails

[Eli Zaretskii]

> Date: Wed, 27 Jul 2005 15:35:27 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> CVS from today:
> 
> D:\ecvs\bld\emacs\nt>make
> Using D:\WINNT\system32\cmd.exe as shell.
> .
> .
> make  -C ../lib-src all
> make[1]: *** No rule to make target `getopt.h', needed by 
> `oo-spd/i386/ctags.o'.  Stop.
> make[1]: Entering directory `D:/ecvs/bld/emacs/lib-src'
> make[1]: Leaving directory `D:/ecvs/bld/emacs/lib-src'
> make: *** [all-other-dirs-gmake] Error 2

I suspect that some w32-specific Makefiles (*/makefile.w32-in) and
probably also nt/*.defs files need an update due to the recent changes
by Paul Eggert that moved around the getopt.* stuff.

I suggest to look at Paul's changes in the various Makefile's and do
the same in the w32 files.

Re: make (bootstrap) fails

[Juanma Barranquero]

On 7/27/05, Eli Zaretskii <eliz@gnu.org> wrote:

> I suspect that some w32-specific Makefiles (*/makefile.w32-in) and
> probably also nt/*.defs files need an update due to the recent changes
> by Paul Eggert that moved around the getopt.* stuff.
> 
> I suggest to look at Paul's changes in the various Makefile's and do
> the same in the w32 files.

I was going to commit the following patch (plus changes to
lib-src/.cvsignore to ignore getopt.h).

Does that seems right, or is there any more elegant way?

-- 
                    /L/e/k/t/u


Index: lib-src/makefile.w32-in
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/makefile.w32-in,v
retrieving revision 2.35
diff -u -2 -r2.35 makefile.w32-in
--- lib-src/makefile.w32-in	4 Jul 2005 15:24:11 -0000	2.35
+++ lib-src/makefile.w32-in	27 Jul 2005 15:02:38 -0000
@@ -287,4 +287,5 @@
 		- $(DEL) *~ DOC* $(COMPILER_TEMP_FILES)
  		- $(DEL) ctags.c
+		- $(DEL) getopt.h
  		- $(DEL_TREE) $(OBJDIR)
 
@@ -301,4 +302,6 @@
  			$(CP) $(ALL_DEPS) $@
  ../src/paths.h:		../nt/paths.h
+			$(CP) $(ALL_DEPS) $@
+getopt.h:		getopt_.h
  			$(CP) $(ALL_DEPS) $@

make bootstrap fails

[Mark Moll]

The latest CVS version of emacs fails to build on 10.2.3 (the problem 
might not be OS X specific, though).

This is what I did:

cvs update -P -d
make distclean
./configure --enable-carbon-app=/Applications --without-x
make bootstrap

Compilation fails in the last step:

gcc  -prebind -framework Carbon -lstdc++ -Xlinker -headerpad -Xlinker 
690  -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o  window.o 
charset.o coding.o category.o ccl.o cm.o term.o xfaces.o  emacs.o 
keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o 
marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o 
casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o 
editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o 
syntax.o unexmacosx.o bytecode.o process.o callproc.o region-cache.o 
sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o 
md5.o  mac.o macterm.o macfns.o macmenu.o fontset.o terminfo.o 
lastfile.o    mktime.o     -lncurses
ld: warning multiple definitions of symbol _PC
terminfo.o definition of _PC in section (__DATA,__common)
/usr/lib/libncurses.dylib(lib_tputs.o) definition of _PC
ld: warning multiple definitions of symbol _BC
terminfo.o definition of _BC in section (__DATA,__common)
/usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC
ld: warning multiple definitions of symbol _UP
terminfo.o definition of _UP in section (__DATA,__common)
/usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP
./temacs --batch --load loadup bootstrap
Loading loadup.el (source)...
Using load-path (/Users/mmoll/src/emacs/lisp 
/Users/mmoll/src/emacs/lisp/emacs-lisp 
/Users/mmoll/src/emacs/lisp/language 
/Users/mmoll/src/emacs/lisp/international 
/Users/mmoll/src/emacs/lisp/textmodes)
Loading byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Loading version.el (source)...
Loading widget (source)...
Loading custom (source)...
Loading map-ynp (source)...
Loading env (source)...
Loading cus-start (source)...
Note, built-in variable `selection-coding-system' not bound
Note, built-in variable `mouse-autoselect-window' not bound
Note, built-in variable `x-use-underline-position-properties' not bound
Loading international/mule (source)...
Loading international/mule-conf.el (source)...
Loading format (source)...
Loading bindings (source)...
Loading files (source)...
Loading cus-face (source)...
Loading faces (source)...
Lists of integers (garbage collection statistics) are normal output
while building Emacs; they do not indicate a problem.
((84045 . 20121) (4956 . 22) (520 . 121) 310101 22130 (8 . 1) (17 . 0) 
(6344 . 460))
Loading loaddefs.el (source)...
((101453 . 5616) (7107 . 0) (528 . 113) 1026729 22130 (34 . 33) (17 . 
0) (12784 . 68))
Loading simple (source)...
Invalid read syntax: "?"
make[1]: *** [bootstrap-emacs] Error 255
make: *** [bootstrap] Error 2

-- 
Mark

Re: make bootstrap fails

[Juanma Barranquero]

On Thu, 13 Feb 2003 17:03:05 -0600, Mark Moll <mmoll@cs.rice.edu> wrote:

> The latest CVS version of emacs fails to build on 10.2.3 (the problem 
> might not be OS X specific, though).

> Loading simple (source)...
> Invalid read syntax: "?"
> make[1]: *** [bootstrap-emacs] Error 255
> make: *** [bootstrap] Error 2

Should be fixed now.


                                                           /L/e/k/t/u

make bootstrap fails

[Kai Großjohann]

This is the error I see:

/----
| Compiling /home/kai/work/gnu/emacs/lisp/emacs-lisp/byte-opt.el
| 
| In byte-optimize-form-code-walker:
| byte-opt.el:525:38:Warning: Function `compiler-macroexpand' from cl package
|     called at runtime
| Wrote /home/kai/work/gnu/emacs/lisp/emacs-lisp/byte-opt.elc
| Compiling /home/kai/work/gnu/emacs/lisp/emacs-lisp/bytecomp.el
| Wrote /home/kai/work/gnu/emacs/lisp/emacs-lisp/bytecomp.elc
| Compiling /home/kai/work/gnu/emacs/lisp/subr.el
| Wrote /home/kai/work/gnu/emacs/lisp/subr.elc
| Compiling /home/kai/work/gnu/emacs/lisp/progmodes/cc-mode.el
| >>Error occurred processing /home/kai/work/gnu/emacs/lisp/progmodes/cc-mode.el: Symbol's function definition is void ((char-table-p))
| make[1]: *** [compile] Error 1
| make[1]: Leaving directory `/export/home/kai/work/gnu/emacs/lisp'
| make: *** [bootstrap] Error 2
\----

I tried to find the offending use of char-table-p, but couldn't.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: make bootstrap fails

[Henrik Enberg]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> | Compiling /home/kai/work/gnu/emacs/lisp/progmodes/cc-mode.el
> | >>Error occurred processing /home/kai/work/gnu/emacs/lisp/progmodes/cc-mode.el: Symbol's function definition is void ((char-table-p))

John Wiegley complained about this yesterday, which I followed up to,
and I also submitted a bug-report, but they seem to have been lost in
the space-time continuum.  Anyway, here's what I found.

It seems like `cc-bytecomp-defun' generates bad code.  I'm not really
sure how it's supposed to work though.  It might not even be worth the
effort avoid warnings in Emacs 19.

If you comment out the line that reads (cc-bytecomp-defun char-table-p)
in cc-vars.el, bootstrapping will work.

-- 
Booting... /vmemacs.el

Re: make bootstrap fails

[Richard Stallman]

We should certainly delete all the cc-bytecomp-defun stuff.  It is an
ugly approach.  However, that code has worked for years, and it has
not been changed, so this must imply a compiler bug somewhere else.
We should investigate that and fix it before deleting
cc-bytecomp-defun.

I was unable to make this fail by recompiling cc-bytecomp and cc-vars.
I can't afford to do a bootstrap--too many meetings today.  But if you
byte-compile-debug to t, you should be able to get a backtrace.  Very
likely investigating that backtrace will make considerable progress.

Re: make bootstrap fails

[Henrik Enberg]

Richard Stallman <rms@gnu.org> writes:

> I was unable to make this fail by recompiling cc-bytecomp and cc-vars.
> I can't afford to do a bootstrap--too many meetings today.  But if you
> byte-compile-debug to t, you should be able to get a backtrace.  Very
> likely investigating that backtrace will make considerable progress.

  I was unable to get a better backtrace.  Both bootstrapping with
  byte-compile-debug globally set to t and just for the cc-*.el files
  produce the same terse error message.

Re: make bootstrap fails

[Richard Stallman]

      I was unable to get a better backtrace.  Both bootstrapping with
      byte-compile-debug globally set to t and just for the cc-*.el files
      produce the same terse error message.

Were you using batch mode?  Can you do it interactively
and get the same error?

Re: make bootstrap fails

[Kenichi Handa]

As it seems that this mail was not delivered correctly, I'll
resend it.  I'm sorry if you get it twice.

In article <E18BBfj-0002Fo-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> We should certainly delete all the cc-bytecomp-defun stuff.  It is an
> ugly approach.  However, that code has worked for years, and it has
> not been changed, so this must imply a compiler bug somewhere else.
> We should investigate that and fix it before deleting
> cc-bytecomp-defun.

> I was unable to make this fail by recompiling cc-bytecomp and cc-vars.

It's because the error happens only while bootstrapping.

> I can't afford to do a bootstrap--too many meetings today.  But if you
> byte-compile-debug to t, you should be able to get a backtrace.  Very
> likely investigating that backtrace will make considerable progress.

I think I find the reason of this error.

It seems that this change

2002-11-06  Dave Love  <fx@gnu.org>

	* international/mule.el (set-buffer-file-coding-system):
	Call ucs-set-table-for-input.

revealed the problem of cc-bytecomp-defun.

cc-bytecomp-defun changes the function definition of the
argument symbol (in the current case; char-table-p) to
cc-bytecomp-ignore while byte-compiling.

While byte-compiling cc-mode.el, the byte compiler loads
warnings.el to display some warning.  But, as warning.el is
not yet compiled, it is loaded via load-with-code-conversion
which leads to the call of set-buffer-file-coding-system.

At this time, as the function definition of char-table-p is
changed as above, we encounter the error.

When I commented out this line in cc-vars.el:
	(cc-bytecomp-defun char-table-p)	; Emacs 19+, XEmacs 20+
the byte-compiling of cc-mode.el succeeded (but
bootstrapping failed later at the other place, I'll report it
in the next mail).

So, I've just installed the attached workaround in HEAD.

This problem is not only for char-table-p.  For instance,
cc-defs.el has this line:

(cc-bytecomp-defun scan-lists)		; 5 args in XEmacs, 3 in Emacs

So, if I insert (scan-lists 1 0 0) somewhere
in the function load-with-code-conversion, the error
	Symbol's function definition is void ((scan-lists))
occurs while compiling cc-mode.el.  :-(

---
Ken'ichi HANDA
handa@m17n.org


2002-11-14  Kenichi Handa  <handa@m17n.org>

	* progmodes/cc-vars.el: Don't cc-bytecomp-defun char-table-p.

*** cc-vars.el.~1.21.~	Mon Apr 22 09:35:36 2002
--- cc-vars.el	Thu Nov 14 16:02:35 2002
***************
*** 46,52 ****
  ;; Silence the compiler.
  (cc-bytecomp-defun get-char-table)	; XEmacs 20+
  (cc-bytecomp-defun char-table-range)	; Emacs 19+
! (cc-bytecomp-defun char-table-p)	; Emacs 19+, XEmacs 20+
  
  ;; Pull in custom if it exists and is recent enough (the one in Emacs
  ;; 19.34 isn't).
--- 46,52 ----
  ;; Silence the compiler.
  (cc-bytecomp-defun get-char-table)	; XEmacs 20+
  (cc-bytecomp-defun char-table-range)	; Emacs 19+
! ;; (cc-bytecomp-defun char-table-p)	; Emacs 19+, XEmacs 20+
  
  ;; Pull in custom if it exists and is recent enough (the one in Emacs
  ;; 19.34 isn't).

Re: make bootstrap fails

[Stefan Monnier]

> cc-bytecomp-defun changes the function definition of the
> argument symbol (in the current case; char-table-p) to
> cc-bytecomp-ignore while byte-compiling.

But the code does:

     (if (and (cc-bytecomp-is-compiling)
	      (= cc-bytecomp-load-depth 0)
	      (not (fboundp ',fun)))
	 (fset ',fun 'cc-bytecomp-ignore))))

and since char-table-p is bound, it should leave char-table-p alone.
So there's still yet-something-else going on.


	Stefan