[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compilation failure
From: |
Werner LEMBERG |
Subject: |
Re: compilation failure |
Date: |
Wed, 30 Mar 2011 08:52:38 +0200 (CEST) |
>> The last two days, `make boostrap' aborts on my GNU/Linux box ...
>> Are there some bigger changes under construction so that this expected
>> currently?
>
> No, it should be working. I'm not observing problems with bzr 103778,
> either with RHEL 5.6 x86-64 (with self-built GCC 4.6.0), or with
> Ubuntu 10.10 x86 (with system-supplied GCC).
Strange. I'm using openSuSE Factory. Interestingly, if I simply
manually say
./temacs -batch -l loadup dump
within my de_DE.UTF-8 locale, it succeeds, but using the command from
the Makefile,
LC_ALL=C ./temacs -batch -l loadup dump
it aborts. Calling gdb, I get the backtrace shown below. Note that
I'm doing a normal build without any additional options.
Werner
======================================================================
#0 mark_object (arg=138477574) at alloc.c:5429
#1 0x08195d4e in mark_maybe_pointer (p=<optimized out>) at alloc.c:4083
#2 mark_memory (offset=0, end=0xbfffed98, start=0x841313a) at alloc.c:4133
#3 mark_stack () at alloc.c:4381
#4 Fgarbage_collect () at alloc.c:4966
#5 0x081aa12d in Feval (form=138874790) at eval.c:2248
#6 0x081aa3dd in Fprogn (args=<optimized out>) at eval.c:343
#7 0x081aa66d in funcall_lambda (fun=138874846, nargs=1,
arg_vector=0xbfffe268) at eval.c:3051
#8 0x081aa8a3 in Ffuncall (nargs=2, args=0xbfffe264) at eval.c:2930
#9 0x081ab048 in funcall_nil (nargs=2, args=0xbfffe264) at eval.c:2419
#10 0x081a950f in run_hook_with_args (nargs=2, args=0xbfffe264,
funcall=0x81ab030 <funcall_nil>)
at eval.c:2608
#11 0x081a96d0 in Frun_hook_with_args (nargs=2, args=0xbfffe264) at eval.c:2469
#12 0x081aab02 in Ffuncall (nargs=3, args=0xbfffe260) at eval.c:2852
#13 0x081e1736 in Fbyte_code (bytestr=<optimized out>, vector=136581181,
maxdepth=24) at bytecode.c:691
#14 0x081aa568 in funcall_lambda (fun=136581125, nargs=1,
arg_vector=0xbfffe3ec) at eval.c:3058
#15 0x081aa8a3 in Ffuncall (nargs=2, args=0xbfffe3e8) at eval.c:2930
#16 0x081aaf95 in call1 (fn=138604082, arg1=138921753) at eval.c:2671
#17 0x081cda6d in Fload (file=138921849, noerror=138490170,
nomessage=138490170, nosuffix=138490170,
must_suffix=138490170) at lread.c:1175
#18 0x081aa0ad in Feval (form=138476214) at eval.c:2265
#19 0x081ccf81 in readevalloop (readcharfun=138603090, stream=0x8446a10,
sourcename=138613193, printflag=0,
unibyte=138490170, readfun=138490170, start=138490170, end=138490170,
evalfun=<optimized out>)
at lread.c:1675
#20 0x081cda2a in Fload (file=138613065, noerror=138490170,
nomessage=138490170, nosuffix=138490170,
must_suffix=138490170) at lread.c:1161
#21 0x081aa0ad in Feval (form=138469934) at eval.c:2265
#22 0x0813e343 in top_level_2 () at keyboard.c:1137
#23 0x081a9011 in internal_condition_case (bfun=0x813e330 <top_level_2>,
handlers=138521714, hfun=
0x813f2a0 <cmd_error>) at eval.c:1407
#24 0x0813eb45 in top_level_1 (ignore=138490170) at keyboard.c:1145
#25 0x081a8f41 in internal_catch (tag=138519730, func=0x813eae0 <top_level_1>,
arg=138490170) at eval.c:1154
---Type <return> to continue, or q <return> to quit---
#26 0x0813f453 in command_loop () at keyboard.c:1100
#27 0x0813f51b in recursive_edit_1 () at keyboard.c:730
#28 0x0813f642 in Frecursive_edit () at keyboard.c:792
#29 0x0813b4ac in main (argc=<optimized out>, argv=0xbfffee64) at emacs.c:1685
Lisp Backtrace:
"garbage-collect" (0xbfffe004)
0x8470fd8 Lisp type 6
"run-hook-with-args" (0xbfffe264)
"do-after-load-evaluation" (0xbfffe3ec)
"load" (0xbfffe574)
"load" (0xbfffe7b4)
- compilation failure, Werner LEMBERG, 2011/03/30
- Re: compilation failure, Paul Eggert, 2011/03/30
- Re: compilation failure,
Werner LEMBERG <=
- Re: compilation failure, Eli Zaretskii, 2011/03/30
- Re: compilation failure, Jim Meyering, 2011/03/30
- Re: compilation failure, Eli Zaretskii, 2011/03/30
- Re: compilation failure, Eli Zaretskii, 2011/03/30
- Re: compilation failure, Eli Zaretskii, 2011/03/30
- Re: compilation failure, Werner LEMBERG, 2011/03/30