[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Adrian Robert
Subject: Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep
Date: Wed, 16 Jul 2008 10:24:53 -0400

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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]