emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS


From: Yavor Doganov
Subject: Re: [Emacs.app dev]: Emacs.app now in GNU Emacs CVS
Date: Wed, 16 Jul 2008 20:54:23 +0300
User-agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.2 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

Miles Bader wrote:
> 
> FWIW, here's a little gdb session with stack backtrace... not very
> useful looking but...
> 
> [It dies even if I just run src/bootstrap-emacs without any arguments]

It fails also on gNewSense 2.0 as well with older versions of the
GNUstep (-base 1.14.1, -gui 0.12.0) libraries.

Further debugging (with GNUstep Base built with libffi, as libffcall
munges the backtrace more aggressively) shows that the fault is in
nsterm.m:

void *
ns_alloc_autorelease_pool ()
/* --------------------------------------------------------------------------
     Allocate a pool for temporary objects (callable from C)
   -------------------------------------------------------------------------- */
{
  return [[NSAutoreleasePool alloc] init];
}

This function is called in emacs.c and it appears that this is the
first ObjC function called at initialization.  Maybe there are
necessary compiler/linker flags and options that are omitted for some
reason (deliberate or not); perhaps it is related to -nostdlib and
-lgcc used in Emacs' build system (for reasons I can't fully
understand) or some other oddity.

If it would be of any help, here is how GNUstep Make compiles a random
GNUstep application on GNU/Linux:

gcc Section.m -c \
              -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG 
-fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -g 
-fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS 
-fgnu-runtime -fconstant-string-class=NSConstantString -I. 
-I/home/yavor/GNUstep/Library/Headers -I/usr/local/include/GNUstep 
-I/usr/include/GNUstep \
               -o obj/Section.o

Link stage:

gcc  -rdynamic      -shared-libgcc -fexceptions -fgnu-runtime -o 
HelpViewer.app/./HelpViewer \
        ./obj/main.o ./obj/mainWindowController.o ./obj/Label.o 
./obj/Controller.o ./obj/FigureCell.o ./obj/Legend.o 
./obj/HandlerStructureXLP.o ./obj/TextFormatterXLP.o ./obj/BrowserCell.o 
./obj/NoteCell.o ./obj/ModNSString.o ./obj/BRCell.o ./obj/Page.o 
./obj/Section.o      -L/home/yavor/GNUstep/Library/Libraries -L/usr/local/lib 
-L/usr/lib     -lgnustep-gui    -lgnustep-base   -lpthread -lobjc   -lm

I tried a dirty workaround by modifying src/Makefile to include the
missing flags, to no avail.

This is, IMVHO, a grave problem caused by miscompilation/linking on
GNU/Linux; but it looks rather obscure to me right now so I am sorry I
can't really help.

It is unfortunate that the Emacs.app developers run primarily Muck OS
and the code was not tested on GNUstep under GNU/Linux.  Anyway, such
failures right after the merge are more or less expected.  I'll dive
into this tomorrow, unless someone fixes the problem.

Nevertheless, it is a great day for all the GNUsteppers who are also
monks in the GNU Emacs Church -- we've been waiting for the Holy Merge
for years.  Thanks to all the people who made it happen, and of course
Adrian for keeping up with Emacs changes through the years.





reply via email to

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