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

Richard Frith-Macdonald <richard <at> 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).

> 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

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep <at> gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep