Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

[Charles philip Chan]

Richard Frith-Macdonald <richard@tiptree.demon.co.uk> writes:

Hello Richard:

> Your application has reached the point of being terminated by an
> uncaught exception handler ... that means that it will have printed
> out the details of the exception to stderr, so you should be able to
> look at that and perhaps get a bit more information.

,----[ stderr ]
| 2008-07-16 06:36:33.353 bootstrap-emacs[6601] autorelease called without pool 
for object (8504ac8) of class NSMethodSignature in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.363 bootstrap-emacs[6601] autorelease called without pool 
for object (85052f0) of class GSCodeBuffer in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.372 bootstrap-emacs[6601] autorelease called without pool 
for object (854e138) of class NSMethodSignature in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.381 bootstrap-emacs[6601] autorelease called without pool 
for object (853b848) of class GSFFIInvocation in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.387 bootstrap-emacs[6601] autorelease called without pool 
for object (8544ce8) of class GSCInlineString in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.395 bootstrap-emacs[6601] autorelease called without pool 
for object (8555b00) of class NSException in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.403 bootstrap-emacs[6601] autorelease called without pool 
for object (8556d90) of class GSMutableArray in thread <NSThread: 0x84f1260>
| ../src/bootstrap-emacs: Uncaught exception NSInvalidArgumentException, 
reason: NSAutoreleasePool(class) does not recognize (null)
| Fatal error (6)gmake[2]: *** 
[/usr/src/packages/BUILD/emacs/lisp/emacs-lisp/bytecomp.elc] Aborted
`----

> However, the fact that the stacktrace shows the method
> doesNotRecognizeSelector: being called means that your problem is a
> message was sent to an object which didn't support it (the log of the
> exception should tell you what type of object received the message and
> what the message was).

Quit
#0  0xb7f26410 in __kernel_vsyscall ()
#1  0xb726cc26 in kill () from /lib/libc.so.6
#2  0x08168526 in abort () at emacs.c:432
#3  0xb77082c1 in _terminate () at NSException.m:697
#4  0xb7708562 in _NSFoundationUncaughtExceptionHandler (exception=0x854a930) 
at NSException.m:724
#5  0xb7708d33 in -[NSException raise] (self=0x854a930, _cmd=0xb7af7a60) at 
NSException.m:864
#6  0xb7708787 in +[NSException raise:format:arguments:] (self=0xb7af74c0, 
_cmd=0xb7af7a48, 
    name=0xb7af7248, format=0xb7b0b040, argList=0xbf8bddd0 "à\035®·\023\230¦·")
    at NSException.m:767
#7  0xb77086bf in +[NSException raise:format:] (self=0xb7af74c0, 
_cmd=0xb7b0b9f0, name=0xb7af7248, 
    format=0xb7b0b040) at NSException.m:753
#8  0xb7752980 in -[NSObject doesNotRecognizeSelector:] (self=0xb7ae20e0, 
_cmd=0xb7b0bae8, 
    aSelector=0x8409570) at NSObject.m:1705
#9  0xb7752b5c in -[NSObject forwardInvocation:] (self=0xb7ae20e0, 
_cmd=0x8465b58, 
    anInvocation=0x853b4c8) at NSObject.m:1733
#10 0xb7808866 in GSFFIInvocationCallback (cif=0x8544900, retp=0xbf8bdf20, 
args=0xbf8bded0, 
    user=0x8544900) at GSFFIInvocation.m:547
#11 0xb6e1a5da in ffi_closure_SYSV_inner (closure=0xb755c000, respp=0xbf8bdf2c, 
args=0xbf8bdf40)
    at src/x86/ffi.c:267
#12 0xb6e1a92a in ffi_closure_SYSV () from /usr/local/lib/libffi.so.5
#13 0x0827a831 in ns_alloc_autorelease_pool () at nsterm.m:519
#14 0x08169dd7 in main (argc=15, argv=0xbf8be384) at emacs.c:1419

> To get round this, you could try getting the latest release of
> gnustep- base, and building it with libffi rather than ffcall (libffi
> also modifies the stack, but in such a way that a stacktrace continues
> to work).

Interesting. Is libffi the preferred library now? If so, this page
should be changed:

http://wwwmain.gnustep.org/resources/downloads.php?site=ftp%3A%2F%2Fftp.gnustep.org%2Fpub%2Fgnustep%2F#pre

Thanks.

Charles

pgpP9LlZDR3Nw.pgp
Description: PGP signature