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

On Jul 16, 2008, at 10:07 AM, Charles philip Chan wrote:

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

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

Lines 99-103 in compile try to get things set up properly (backed up  
by configure.in) and followed by Makefile.in (search for "GNUSTEP" in  
those files).  There have been changes in GNUstep from time to time  
that needed to be adjusted for in the past, and the methods there  
might be failing now.

If the compile and link lines are correct the next thing to look at is  
the init sequence in emacs.c.  At some point in the past the main()  
override to set up NSProcessInfo was causing problems, but I think  
this was resolved.  You could take a look at the patches at:

http://sourceforge.net/tracker/?atid=770756&group_id=148174&func=browse

although these are against a very old version of Emacs.app and so  
should be taken with a grain of salt.