[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: build error
From: |
Eli Zaretskii |
Subject: |
Re: build error |
Date: |
Sat, 15 Sep 2007 13:28:58 +0300 |
> From: "d.henman" <address@hidden>
> Date: Fri, 14 Sep 2007 11:36:55 +0900
> cc:
>
> In end of data:
> bytecomp.el:4255:1:Warning: the function `compilation-forget-errors' is not
> known to be defined.
> Wrote /usr/cvs/emacs/lisp/emacs-lisp/bytecomp.elc
> Compiling /usr/cvs/emacs/lisp/subr.el
> Fatal error (6)/bin/sh: line 4: 3088 Aborted (core dumped)
> EMACSLOADPATH=/usr/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
>
> --- end of paste
>
> I get from this, that subr.el is the file being compliled when core is
> dumped, and
> that this is a compiler fatal error #6 ?
Yes. Fatal error 6 is SIGABRT (see your signal.h header file), as the
"Aborted" part says. If Emacs was aborted, it means that Emacs exited
abnormally, most probably via the call to the `abort' function. The
Emacs sources routinely place the calls to that function where there
are situations that ``cannot happen'', in order to force a core dump
that can be debugged to find the reasons.
But it could also be that /bin/sh (presumably the Cygwin port of Bash)
was the one who aborted, in which case it's a more complicated problem
than just an Emacs bug.
> or line #4 in some file (can't be the .el file)and 3088 being I don't now a
> line# or error #.
It should be line 4 in some shell script, perhaps generated by Make.
3088 is the PID of the process that crashed, I think.
> There is a "bootstrap-emacs.exe.stackdump" being created in the lisp
> directory.
That's the Cygwin equivalent of the core dump file. And it seems to
tell that it was Emacs who crashed, not Bash.
As Richard says, it's better to run bootstrap-emacs under GDB, place a
breakpoint in the `abort' function, and when it breaks, look around to
find out why it wound up calling `abort'.
Btw, isn't this a problem similar to what is described in etc/PROBLEMS
(look under "Building the Cygwin port for MS-Windows can fail with
some GCC versions")? Are you sure you are using one of the GCC
versions named there as ``safe''?