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

[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.

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]

What compiler are you using?  Maybe -g has an effect other than
adding debugging information.

It is also possible that unexec manages to handle one case
and not the other.

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

build failure

[Jean-Marie Gaillourdet]

1;2c

build failure

[Sean Sieger]

I just now did cvs update ...

make[2]: *** No rule to make target
`/home/sean/emacs/lisp/cedet/cedet-cscope.elc', needed by
`compile-main'.  Stop.
make[2]: Leaving directory `/home/sean/emacs/lisp'
make[1]: *** [lisp] Error 2
make[1]: Leaving directory `/home/sean/emacs'
make: *** [bootstrap] Error 2

Re: build failure

[Glenn Morris]

Sean Sieger wrote:

> I just now did cvs update ...
>
> make[2]: *** No rule to make target
> `/home/sean/emacs/lisp/cedet/cedet-cscope.elc', needed by
> `compile-main'.  Stop.

Crystal ball says:
always use `cvs update -dP', as documented in INSTALL.CVS.

Re: build failure

[Sean Sieger]

    Crystal ball says:
    always use `cvs update -dP', as documented in INSTALL.CVS.

Thank you for causing me to read that, Glenn.

build failure

[Erich Neuwirth]

I just pulled the latest version of the sources on my MacBook with OSX 10.8.1

Buildung does not work any more, here is the error.
Loading /Users/neuwirth/devel/org-mode/lisp/org-compat.el (source)...
Cannot open load file: ../UTILITIES/org-fixup.el
make[1]: *** [org-version.el] Error 255
make: *** [all] Error 2

So I installed the latest version from ELPA, when I try C-c C-c on the following code segment


#+begin_src R :session *RPisa* :results value
2*3
#+end_src

I get the error

Symbol's value as variable is void: org-current-export-file

I get the same error with the minimal code segment

#+begin_src R  
2*3
#+end_src

Re: build failure

[Bastien]

Hi Erich,

Erich Neuwirth <erich.neuwirth@univie.ac.at> writes:

> I just pulled the latest version of the sources on my MacBook with OSX 10.8.1
>
> Buildung does not work any more, here is the error.
> Loading /Users/neuwirth/devel/org-mode/lisp/org-compat.el (source)...
> Cannot open load file: ../UTILITIES/org-fixup.el
> make[1]: *** [org-version.el] Error 255
> make: *** [all] Error 2

Looks like you're behind commit bf352eced, where org-compat.el has been
updated so that it loads utils/org-fixup.el, not UTILITIES/org-fixup.el

Please pull again from git, this is fixed there.

> So I installed the latest version from ELPA

Yes -- still several things to fix to get a working ELPA version.
We're on it.

Let us know if git pull does it for you.  Thanks!

-- 
 Bastien

Re: build failure

[Achim Gratz]

Erich Neuwirth writes:
> I just pulled the latest version of the sources on my MacBook with OSX 10.8.1
>
> Buildung does not work any more, here is the error.
> Loading /Users/neuwirth/devel/org-mode/lisp/org-compat.el (source)...
> Cannot open load file: ../UTILITIES/org-fixup.el
> make[1]: *** [org-version.el] Error 255
> make: *** [all] Error 2

This report is unfortunately not very useful since you don't give any
information at what commit you are.  This is especially irksome as that
information would have been in the output just one line above where
you've cut...

So my best guess is that you just need to run make again and all is well
(and since utils/ has now been renamed mk/ it may happen once again).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: build failure

[Neuwirth Erich]

Pulling the latest version and building it made the problem disappear.
org-version says
7.9 (release_7.9-80-gf29660.dirty)


On Aug 26, 2012, at 10:50 PM, Bastien <bzg@altern.org> wrote:

> Hi Erich,
> 
> Erich Neuwirth <erich.neuwirth@univie.ac.at> writes:
> 
>> I just pulled the latest version of the sources on my MacBook with OSX 10.8.1
>> 
>> Buildung does not work any more, here is the error.
>> Loading /Users/neuwirth/devel/org-mode/lisp/org-compat.el (source)...
>> Cannot open load file: ../UTILITIES/org-fixup.el
>> make[1]: *** [org-version.el] Error 255
>> make: *** [all] Error 2
> 
> Looks like you're behind commit bf352eced, where org-compat.el has been
> updated so that it loads utils/org-fixup.el, not UTILITIES/org-fixup.el
> 
> Please pull again from git, this is fixed there.
> 
>> So I installed the latest version from ELPA
> 
> Yes -- still several things to fix to get a working ELPA version.
> We're on it.
> 
> Let us know if git pull does it for you.  Thanks!
> 
> -- 
> Bastien

Re: build failure

[Achim Gratz]

Neuwirth Erich <erich.neuwirth <at> univie.ac.at> writes:
> Pulling the latest version and building it made the problem disappear.
> org-version says
> 7.9 (release_7.9-80-gf29660.dirty)

What have you changed to make it "dirty"?


Regards,
Achim.

build failure

[Sean Sieger]

/bin/makeinfo --force -I./../emacs --no-split -o ../../info/org.info ./org.texi
./org.texi:6: @include `org-version.inc': No such file or directory.
./org.texi:278: warning: undefined flag: VERSION.
./org.texi:309: warning: undefined flag: VERSION.
make[3]: *** [../../info/org.info] Error 1
make[3]: Leaving directory `/c/trunk/doc/misc'
make[2]: *** [misc-info] Error 2
make[2]: Leaving directory `/c/trunk'
make[1]: *** [info] Error 2
make[1]: Leaving directory `/c/trunk'
make: *** [bootstrap] Error 2

Re: build failure

[Bastien]

Sean Sieger <sean.sieger@gmail.com> writes:

> /bin/makeinfo --force -I./../emacs --no-split -o ../../info/org.info ./org.texi
> ./org.texi:6: @include `org-version.inc': No such file or directory.
> ./org.texi:278: warning: undefined flag: VERSION.
> ./org.texi:309: warning: undefined flag: VERSION.
> make[3]: *** [../../info/org.info] Error 1
> make[3]: Leaving directory `/c/trunk/doc/misc'
> make[2]: *** [misc-info] Error 2
> make[2]: Leaving directory `/c/trunk'
> make[1]: *** [info] Error 2
> make[1]: Leaving directory `/c/trunk'
> make: *** [bootstrap] Error 2

Fixed, thanks.

-- 
 Bastien

Build failure

[John]

On one of my computers (running openSuSE GNU/Linux) building from master
fails with

^[7^[]2;jpff on cage: /home/jpff/GNU/emacs\a^[]1;cage\a^[8
^[[4mcage^[[24m:^[[1m~/GNU/emacs^[[0m> 

^[[4mcage^[[24m:^[[1m~/GNU/emacs^[[0m> make 

make -C lib all
make[1]: Entering directory '/home/jpff/GNU/emacs/lib'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/jpff/GNU/emacs/lib'
make -C lib-src all
make[1]: Entering directory '/home/jpff/GNU/emacs/lib-src'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/jpff/GNU/emacs/lib-src'
make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all
make[1]: Entering directory '/home/jpff/GNU/emacs/src'
make -C ../admin/charsets all
make[2]: Entering directory '/home/jpff/GNU/emacs/admin/charsets'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/admin/charsets'
make -C ../admin/unidata charscript.el
make[2]: Entering directory '/home/jpff/GNU/emacs/admin/unidata'
make[2]: Nothing to be done for 'charscript.el'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/admin/unidata'
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Entering directory '/home/jpff/GNU/emacs/admin/unidata'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/admin/unidata'
make -C ../admin/charsets cp51932.el
make[2]: Entering directory '/home/jpff/GNU/emacs/admin/charsets'
make[2]: Nothing to be done for 'cp51932.el'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/admin/charsets'
make -C ../admin/charsets eucjp-ms.el
make[2]: Entering directory '/home/jpff/GNU/emacs/admin/charsets'
make[2]: Nothing to be done for 'eucjp-ms.el'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/admin/charsets'
make[1]: Leaving directory '/home/jpff/GNU/emacs/src'
make -C lisp all
make[1]: Entering directory '/home/jpff/GNU/emacs/lisp'
make -C ../leim all EMACS="../src/emacs"
make[2]: Entering directory '/home/jpff/GNU/emacs/leim'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/leim'
make -C ../admin/grammars all EMACS="../../src/emacs"
make[2]: Entering directory '/home/jpff/GNU/emacs/admin/grammars'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/jpff/GNU/emacs/admin/grammars'
make[2]: Entering directory '/home/jpff/GNU/emacs/lisp'
  ELC      gnus/gnus-agent.elc
Eager macro-expansion failure: (file-error "Testing file" "Permission denied" "/etc/news/organization")

In toplevel form:
gnus/gnus-agent.el:26:1:Error: Testing file: Permission denied, /etc/news/organization
make[2]: *** [Makefile:296: gnus/gnus-agent.elc] Error 1
make[2]: Leaving directory '/home/jpff/GNU/emacs/lisp'
make[1]: *** [Makefile:319: compile-main] Error 2
make[1]: Leaving directory '/home/jpff/GNU/emacs/lisp'
make: *** [Makefile:411: lisp] Error 2
^[[4mcage^[[24m:^[[1m~/GNU/emacs^[[0m> exit


Script done on 2019-09-21 15:15:14+01:00 [COMMAND_EXIT_CODE="0"]


It happens in gnus and org,  either of which I actually use.  What
does it mean?  I have other computers running the same OS which seem OK.
==John ffitch

Re: Build failure

[Lars Ingebrigtsen]

John <jpff@codemist.co.uk> writes:

> It happens in gnus and org,  either of which I actually use.  What
> does it mean?  I have other computers running the same OS which seem OK.

It's a known problem in file-readable-p; it's being worked on.  See
bug#37475.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Build failure

[Paul Eggert]

On 9/21/19 8:27 AM, Lars Ingebrigtsen wrote:
> It's a known problem in file-readable-p; it's being worked on.  See
> bug#37475.

Should be fixed now.