>>>> "ZW" == Zack Weinberg
<zack(a)wolery.cumb.org> writes:
ZW> On Wed, Feb 02, 2000 at 09:04:53PM -0800, Martin Buchholz wrote:
> Because I'm insane, I compile XEmacs with C++ compilers. I
get a
> crash when building with egcs-20000131 c++.
ZW> I cannot reproduce this crash with gcc-20000129 c++ on ix86-linux. I
ZW> will try again with top of trunk, but you may be interested in the
ZW> details.
ZW> I configured with CC=gcc-2000129, then edited config.status to make
ZW> CC, XEMACS_CC, etc. equal to g++-2000129, reran config.status, and
ZW> built. (Due to bugs in Autoconf, configure bombs out if you make CC
ZW> a C++ compiler.)
Wow! I didn't expect you to do this!
Compiling with a C++ compiler is `unsupported'. I do it primarily as
a useful quality exercise. The more compilers your code has seen, the
more likely it is to work on some stranger's system. This is also why
I randomly build with -fsigned-chars, for example.
The way I do it (simplified) is
CC=gcc-2000129 XEMACS_CC=g++-20000129 configure ...
make
ZW> A lot of the code in the lib-src directory needed to be worked over
ZW> before it would compile. I can send the patch if anyone cares.
Because autoconf is not C++ clean, you need to configure with a C
compiler, then `make' with a C++ compiler. I only do this for the
xemacs binary itself. The problem with lib-src is that much of the
code is imported from other maintainers. For example, etags.
ZW> The makefile attempts to link temacs by hand and gets it horribly
ZW> wrong, causing the built temacs to crash inside libc startup code.
ZW> You're doing something like gcc -nostdlib pre-crt0.o /usr/lib/crt1.o
ZW> /usr/lib/crti.o <objects> <X libraries> -ldl -lgcc /usr/lib/crtn.o
All of this will go away near term, once we switch to the `Portable Dumper'.
ZW> First off, -nostdlib doesn't turn off automatic linking with crt1 in
ZW> all versions of gcc. You need -nostartfiles too. Second, you
ZW> forgot /usr/lib/gcc-lib/TARGET/VERSION/crtbegin.o and .../crtend.o,
ZW> which means global constructors won't be run. (I think this is why
ZW> it crashes; libc has global constructors.) Third, you forgot libc!
ZW> It gets dragged in by dependencies of the other libraries, but not
ZW> properly.
ZW> None of this nonsense is actually necessary; the only point that I
ZW> can see is to define 'data_start', and crt1.o does that for you on
ZW> this platform.
ZW> Once I fixed that, the build then completed successfully. I
ZW> dumped xemacs from within gdb, as you did, with no errors.
ZW> make check gets some errors, but these appear to be unrelated.
These are OK.
ZW> $ make check
ZW> cd ./src && make check
ZW> make[1]: Entering directory `/work/build/xemacs/src'
ZW> ./xemacs -batch -l \
ZW> /work/src/xemacs-21.2/src/../tests/automated/test-harness.el -f \
ZW> batch-test-emacs /work/src/xemacs-21.2/src/../tests/automated
ZW> Testing /work/src/xemacs-21.2/tests/automated/base64-tests.el...
ZW> base64-tests.el: 1232 of 1232 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/byte-compiler-tests.el...
ZW> Unexpected error (void-function defadvice) while executing interpreted code.
ZW> Test suite execution aborted.
ZW> Unexpected error (void-variable message) while executing byte-compiled code.
ZW> Test suite execution aborted.
ZW> byte-compiler-tests.el: No tests run
ZW> Test suite execution failed unexpectedly.
ZW> Testing /work/src/xemacs-21.2/tests/automated/database-tests.el...
ZW> database-tests.el: No tests run
ZW> Testing /work/src/xemacs-21.2/tests/automated/hash-table-tests.el...
ZW> hash-table-tests.el: 8570 of 8570 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/lisp-tests.el...
ZW> lisp-tests.el: 3262 of 3262 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/md5-tests.el...
ZW> md5-tests.el: 56 of 56 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/mule-tests.el...
ZW> mule-tests.el: 2 of 2 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/symbol-tests.el...
ZW> symbol-tests.el: 226 of 226 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/syntax-tests.el...
ZW> syntax-tests.el: 56 of 56 (100%) tests successful.
ZW> Done
ZW> I conclude: either the problem you hit was introduced after the
ZW> 20000129 snapshot, or it was caused by old object files or C/C++
ZW> incompatibilities.
Also, the development work is on a branch, not the trunk. (We're
planning to fix that someday).
http://cvs.xemacs.org/
I offer a login to my machine, so that you can see the crash in
person. Happens reliably. Send me your ssh public key.
Bug happens in both egcs-20000124 and egcs-20000131.
I think the difference in the stack traces for the functions was only
the absence/presence of -g and -O3 flags. After all, this is an
optimizer bug, but debugging is helped by _not_ optimizing.
Here is a stack trace containing exclusively
make CFLAGS='-g -O3'
object files.
(gdb) where 10
#0 0x40293111 in __kill ()
#1 0x40292d66 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x40294447 in abort () at ../sysdeps/generic/abort.c:88
#3 0x8085891 in assert_failed () at /xemacs/ws/dev/src/emacs.c:2818
#4 0x8052ff2 in make_uninit_string__Fl (length=-1) at /xemacs/ws/dev/src/alloc.c:1858
#5 0x80575b8 in make_string__FPCUcl (contents=0x8395a80 "Loading
/xemacs/build/moS+/lisp/keydefs.elc...", length=-1) at
/xemacs/ws/dev/src/alloc.c:2112
#6 0x812178e in echo_area_message__FP5framePCUcllll (f=0x82d1af8, nonreloc=0x0,
reloc=137720740, offset=0, length=-1, label=136699748) at
/xemacs/ws/dev/src/minibuf.c:740
#7 0x8121a38 in message__FPCce (fmt=0x81be828 "Loading %s...") at
/xemacs/ws/dev/src/minibuf.c:810
#8 0x8118164 in Fload_internal__Fllllll (file=137710860, no_error=136581276,
nomessage=136581276, nosuffix=136581276, codesys=136581276, used_codesys=136581276) at
/xemacs/ws/dev/src/lread.c:674
#9 0x8089ac1 in Feval__Fl (form=137207320) at /xemacs/ws/dev/src/eval.c:2974
(More stack frames follow...)