GNU bug report logs - #2264
Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)

Previous Next

Full log

View this message in rfc822 format

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: 2264 <at> debbugs.gnu.org
Subject: bug#2264: 23.0; Emacs.app does not load ~/.emacs
Date: Sat, 7 Mar 2009 12:36:13 +0200

[Message part 1 (text/plain, inline)]

> One possible way to solve the problem is to use NSZone functions
> wrapped and callable from C.  But unexmacosx.c does some low-level
> things which are not possible with NSZone.  So it is doubtful if this
> approach would succeed at all.

The NSZone stuff is what I meant.  I didn't realize Andrew Choi  
ripped out the NSZone stuff when replaced it with malloc_zone when he  
rewrote unexnext but hopefully the difference is not important, and  
this is one reason why unexnext would be a better model.  I'm not  
sure the extra stuff in unexmacosx is needed under GNUstep, because  
it might relate to MACH rather than ELF.

Basically, the unexelfgs file that would be needed (not sure if it  
would be better to ifdef it in unexelf or make a new file) would  
combine the zone alloc stuff needed to keep objc working happily  
together with the existing strategies in unexelf for dealing with ELF  
(instead of the MACH-O strategies in unexnext/osx).

Here are two version of the unexnext.c file (I'm cc'ing the bug  
report so they're available online).  The first was unchanged over  
some years.  The second one was updated by me to RUN on OS X 10.4 and  
up.  I'm not sure which one, if either, would be more compatible with  
GNUstep, since the differences may only relate to MACH stuff.

[unexnext.c (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

[unexnext.c (application/octet-stream, attachment)]

[Message part 5 (text/plain, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.