Re: Emacs 23.x from CVS 20090228

[Richard Frith-Macdonald]

On 3 Mar 2009, at 08:34, Gürkan Sengün wrote:

> Hi
>
> The command I use is this:
> ./configure --with-x=no; make bootstrap; ./configure --with-ns; make
>
> The GNUstep version I have is the latest gnustep tarballs on Linux.
>
> When I try to build emacs.app (gnustep gui version) I end up with  
> this:
>
> NSConstantString -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 - 
> DGNU_RUNTIME=1 -DGSWARN -DGSDIAGNOSE nsterm.m
> nsterm.m: In function 'ns_update_end':
> nsterm.m:655: warning: 'NSView' may not respond to '- 
> unlockFocusNeedsFlush:'
> nsterm.m:655: warning: (Messages without a matching method signature
> nsterm.m:655: warning: will be assumed to return 'id' and accept
> nsterm.m:655: warning: '...' as arguments.)
> nsterm.m: In function 'ns_term_shutdown':
> nsterm.m:4008: error: 'SIGTERM' undeclared (first use in this  
> function)
> nsterm.m:4008: error: (Each undeclared identifier is reported only  
> once
> nsterm.m:4008: error: for each function it appears in.)

Looks like a bug in nsterm.c then ... presumably the configure script  
needs to check for the correct header for signal constants, and  
nsterm.m needs to make use of the results of that check.

> nsterm.m: In function '-[EmacsView setMarkedText:selectedRange:]':
> nsterm.m:4691: warning: pointer type mismatch in conditional  
> expression
> nsterm.m: In function '-[EmacsView conversationIdentifier]':
> nsterm.m:4782: warning: conflicting types for '- 
> (NSInteger)conversationIdentifier'
> /usr/include/GNUstep/AppKit/NSInputManager.h:53: warning: previous  
> declaration of '-(long int)conversationIdentifier'

This is just a warning, not an error ... it's arising because gnustep- 
base has switched over to the MacOS 10.5 API and the rest of GNUstep  
hasn't.

It would be good if people could contribute patches to update core  
libraries (essentially to use NSUInteger, NSInteger, and CGFloat  
everywhere in the external API rather than using unsigned int/long,  
int/long, or float).
Generally speaking this should make no different to the ABI on 32bit  
systems, but it's going to be a fairly big upheaval on 64bit systems.