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

[Richard Frith-Macdonald]

On 16 Jul 2008, at 03:14, Charles philip Chan wrote:

> Adrian Robert <adrian.b.robert@gmail.com> writes:
>
> > Hmm, I'm wondering why things get lost here..  It's been a while,
> > maybe this is something inevitable, but I also remember when I was
> > doing this a lot I would build Emacs.app with no optimization (remove
> > -O2 in the compile script) and also use the debug version of the
> > GNUstep libraries (I forget how I did this).  This definitely helps
> > gdb.
>
> Here is the back trace done with the debug version of GNUstep:
>
> Starting program: /usr/src/packages/BUILD/emacs/src/bootstrap-emacs - 
> batch --no-site-file --multibyte -l autoload --eval \(setq\ generate- 
> autoload-cookie\ \ \ \ \ \ \ \ \ \ \ \ \ \"\;\;\;\#\#\#cal-autoload 
> \"\) --eval \(setq\ generated-autoload-file\ \ \ \ \ \ \ \ \ \ \ \ \  
> \ \ \ \ \ \ \ \ \ \ \ \ \"/usr/src/packages/BUILD/emacs/lisp/ 
> calendar/cal-loaddefs.el\"\) --eval \(setq\ make-backup-files\ nil\)  
> -f batch-update-autoloads /usr/src/packages/BUILD/emacs/lisp/calendar
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb6c1e6d0 (LWP 10708)]
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb6c1e6d0 (LWP 10708)]
> 0xb7fca410 in __kernel_vsyscall ()
> #0  0xb7fca410 in __kernel_vsyscall ()
> #1  0xb730fc26 in kill () from /lib/libc.so.6
> #2  0x08168526 in abort () at emacs.c:432
> #3  0xb77aa245 in _terminate () at NSException.m:697
> #4  0xb77aa4e6 in _NSFoundationUncaughtExceptionHandler  
> (exception=0x854b1b8) at NSException.m:724
> #5  0xb77aacb7 in -[NSException raise] (self=0x854b1b8,  
> _cmd=0xb7b9ba20) at NSException.m:864
> #6  0xb77aa70b in +[NSException raise:format:arguments:]  
> (self=0xb7b9b480, _cmd=0xb7b9ba08,
>    name=0xb7b9b208, format=0xb7baf000, argList=0xbf99966c " ]¸·sÞ 
> °·") at NSException.m:767
> #7  0xb77aa643 in +[NSException raise:format:] (self=0xb7b9b480,  
> _cmd=0xb7baf9b0, name=0xb7b9b208,
>    format=0xb7baf000) at NSException.m:753
> #8  0xb77f4904 in -[NSObject doesNotRecognizeSelector:]  
> (self=0xb7b860a0, _cmd=0xb7bafaa8,
>    aSelector=0x8409570) at NSObject.m:1705
> #9  0xb77f4ae0 in -[NSObject forwardInvocation:] (self=0xb7b860a0,  
> _cmd=0x8465b38,
>    anInvocation=0x853be68) at NSObject.m:1733
> #10 0xb78acb3a in GSInvocationCallback (callback_data=0xb7bfb7c0,  
> args=0xbf9997f4)
>    at GSFFCallInvocation.m:1047
> #11 0xb6ebe7d5 in __vacall_r () from /usr/local/lib/libcallback.so.0
> #12 0xb7bfb7c0 in returnTypeInfo ()
>   from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.17
> #13 0xbf9997f4 in ?? ()
> #14 0x00000004 in ?? ()
> #15 0xbf999828 in ?? ()
> #16 0x00000000 in ?? ()
> The program is running.  Exit anyway? (y or n)

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.

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

Unfortunately, what you can't tell from this is where in the code the  
problem occurred.  This is because your GNUstep base library was built  
to use the ffcall library, and the ffcall library modifies the stack  
in such a way that a stacktrace is confused at the point where ffcall  
got involved.
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).