Re: Build Failure

Re: Build Failure

[Eli Zaretskii]

Nick Brown wrote:
> 
> /emacs -q -batch -f list-load-path-shadows
> make[1]: *** [emacs] Illegal Instruction (core dumped)
> make[1]: Leaving directory `/users/nicbrown/emacs-21.2/src'
> (export PARALLEL; PARALLEL=0; cd leim; make all  \
>   CC='gcc' CFLAGS='-g -O2 ' CPPFLAGS='' \
>   LDFLAGS='' MAKE='make')

Thanks.

Can you please see in the debugger where does it crash?  Here are the
commands to do that if you have GDB installed (the same should work with
dbx):

	cd /users/nicbrown/emacs-21.2/src
	gdb ./emacs core
	where

Please post the debugger's output here.

Re: Build Failure

[Eli Zaretskii]

> From: Nick Brown <nicbrown@cisco.com>
> Newsgroups: gnu.emacs.bug
> Date: Tue, 07 May 2002 12:57:49 +0100
> 
> (gdb) where
> #0  0x1ee824 in __DTOR_END__ ()
> (gdb)

Thanks.

Unfortunately, this is of no use: it seems like your Emacs binary is
stripped, so there's no debug info there, and GDB cannot print the
backtrace of function calls that led to the crash for lack of that
information.

Can you build Emacs with the -g switch, run the unstripped binary,
and when it crashes, do what you've done here again, this time with
the unstripped binary?

TIA

Re: Build Failure

[Eli Zaretskii]

> From: Nick Brown <nicbrown@cisco.com>
> Newsgroups: gnu.emacs.bug
> Date: Tue, 07 May 2002 16:06:50 +0100
> 
> How do I do that?
> I previously just did a;
> configure --prefix='/users/nicbrown/software/test' --without-x
> make
> make install
> 
> the make.log (attached to my first post) seem to show the -g option, but I 
> don't know how to make un an unstripped version.

If that's how you made Emacs, the binary in the `src' directory should
be unstripped.  Hmm, I wonder why didn't you get a backtrace then.

Maybe it's your GDB version--it sounds very old (1996 was a long time
ago, and it also complained about some part of the .gdbinit file).
What does "gdb --version" print?

Can you try to build the latest GDB and use that, or use dbx?

Another idea is to run Emacs under GDB to begin with, exactly like it
was run by Make when it crashed, and see what happens then.  Here are
the necessary steps, starting from the top-level directory where you
unpacked the Emacs sources:

    cd src
    gdb ./emacs
    (gdb) run -q -batch -f list-load-path-shadows

If all goes well, this should cause the same crash you see during the
build, but this time GDB will kick in, and you should be able to type
the "bt" (or "where") command to display the backtrace.

Re: Build Failure

[Ralf Fassel]

* nicbrown@cisco.com (Nick Brown)
| How do I do that?
| I previously just did a;
| configure --prefix='/users/nicbrown/software/test' --without-x

Try

  env CFLAGS=-g configure --prefix ...

R'c

Re: Build Failure

[Richard Stallman]

    But the big question is, why when I use the default -O2 and don't specify 
    --without-x does it built just fine !?

    the optimisation error obviously only relates to stuff that's included for 
    emacs when there is no X support. any ideas?

You can try compiling various files with different flags
and determine which file is the locus of the problem.

Then you can try splitting that file into two parts, compiling each
part differently, and moving some things between the parts.
then you can find which function is the locus of the problem.

Then someone could study the erroneous assembler code made for that
function and try to find the GCC bug.

But before trying any of this, how about if you install the latest GCC
release and see if it still fails.  There is no point in your spending
time to debug a GCC bug that has been fixed already.

DDD or IDE? (was Re: Build Failure)

[Tom E. Turner]

I was wondering if anyone has successfully resolved  
build failures with the Data Display Debugger (DDD) 
or any IDE?

http://linux.cis.nctu.edu.tw/docs/ddd/#Summary
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
The Data Display Debugger (DDD) is a popular graphical user 
interface for command-line debuggers such as GDB, DBX, JDB,
WDB, XDB, the Perl debugger, and the Python debugger. Besides 
``usual'' front-end features such as viewing source texts, 
DDD has become famous through its interactive graphical data 
display, where data structures are displayed as graphs. 
A simple mouse click dereferences pointers or views structure
contents, updated each time the program stops. Using DDD, 
you can reason about your application by watching its data, 
not just by viewing it execute lines of source code. 

Other DDD features include: debugging of programs written
in Ada, C, C++, Chill, Fortran, Java, Modula, Pascal, Perl,
and Python; machine-level debugging; hypertext source
navigation and lookup; breakpoint, watchpoint, backtrace, and
history editors; array plots; undo/redo; preferences and
settings editors; program execution in terminal emulator
window; debugging on remote host; on-line manual;
extensive help on the Motif user interface; command-line
interface with full editing, history, and completion
capabilities. 

DDD is generally regarded as one of the best debuggers
available. It is being used for software development by all
major suppliers of information technology and is actively
maintained by its co-author, Andreas Zeller at the Software
Technology Dept., Technische Universitdt Braunschweig,
Germany. 

Finally, DDD is free! DDD is open source software under the
GNU license. All we'd like you to do do is to write a picture
postcard. 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   Envelope-to: tom@gnu.org
   X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f
   From: Richard Stallman <rms@gnu.org>
   CC: gnu-emacs-bug@prep.ai.mit.edu
   Reply-to: rms@gnu.org
   Sender: bug-gnu-emacs-admin@gnu.org
   Date: Sat, 15 Jun 2002 15:47:33 -0600 (MDT)

       But the big question is, why when I use the default -O2 and don't specify 
       --without-x does it built just fine !?
       the optimisation error obviously only relates to stuff that's included for 
       emacs when there is no X support. any ideas?

   You can try compiling various files with different flags
   and determine which file is the locus of the problem.

   Then you can try splitting that file into two parts, compiling each
   part differently, and moving some things between the parts.
   then you can find which function is the locus of the problem.

   Then someone could study the erroneous assembler code made for that
   function and try to find the GCC bug.

   But before trying any of this, how about if you install the latest GCC
   release and see if it still fails.  There is no point in your spending
   time to debug a GCC bug that has been fixed already.


   _______________________________________________
   Bug-gnu-emacs mailing list
   Bug-gnu-emacs@gnu.org
   http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: Build Failure

[Richard Stallman]

I think this problem needs a Solaris wizard.  But I suspect the
problem is related to unexec or to use of malloc.

If you see that some Emacs versions work and some fail,
you could try looking for differences between them
that are in unexec or the code that uses malloc, or in the
flags that control these things.  By installing some subsets
of those differences, you might be able to see which ones
trigger the problem.  That would be a good step towards
solving it.