> This line is just:
>
> return [NSAutoreleasePool alloc] init];

> Error for such a basic call points to a problem with init sequence
> (main() wizardry) or compile/link flags. When I was working on
> Emacs.app and GNUstep the hardest part was getting the compile and
> link lines to look like what happens when you invoke gnustep-make
> (which can't be used for emacs due to its own big build system).
> ...

>
> On 16 Jul 2008, at 12:54, Charles philip Chan wrote:

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

>
> So now you know where the problem occurs ... line 519 of nsterm.m ...
> maybe that's some help.

> I suppose so ... the rationale for preferring ffcall was that it
> worked on more platforms, but with the latest releases of GNUstep-base
> I believe this is no longer the case.

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

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

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