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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2264 in the body.
You can then email your comments to 2264 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)
Date: Tue, 10 Feb 2009 09:55:18 +0200

Thank you for trying to build the GNUstep port.  I've been holding
these changes for far too long.

(I wonder why this message didn't get a bug number assigned?  Perhaps
because it was posted to the newsgroup first...)


2009-02-10  Yavor Doganov  <yavor <at> gnu.org>  (tiny change)

	* nsterm.m: Include <signal.h>.

	* nsfns.m (ns_appkit_version_int): Fix typo in the version macro.

Index: src/nsfns.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsfns.m,v
retrieving revision 1.36
diff -u -r1.36 nsfns.m
--- src/nsfns.m	23 Jan 2009 09:58:03 -0000	1.36
+++ src/nsfns.m	10 Feb 2009 07:47:51 -0000
@@ -974,7 +974,7 @@
 ns_appkit_version_int ()
 {
 #ifdef NS_IMPL_GNUSTEP
-  return GNUSTEP_GUI_MAJOR_VERSION * 100 + GNUSTEP_GNU_MINOR_VERSION;
+  return GNUSTEP_GUI_MAJOR_VERSION * 100 + GNUSTEP_GUI_MINOR_VERSION;
 #elif defined(NS_IMPL_COCOA)
   return (int)NSAppKitVersionNumber;
 #endif
Index: src/nsterm.m
===================================================================
RCS file: /sources/emacs/emacs/src/nsterm.m,v
retrieving revision 1.58
diff -u -r1.58 nsterm.m
--- src/nsterm.m	7 Feb 2009 11:04:07 -0000	1.58
+++ src/nsterm.m	10 Feb 2009 07:47:54 -0000
@@ -30,6 +30,7 @@
 #include "config.h"
 
 #include <math.h>
+#include <signal.h>
 #include <sys/types.h>
 #include <time.h>
 #include <unistd.h>

Message #14 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Cc: yavor <at> gnu.org
Subject: Re: bug#2264: Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)
Date: Tue, 10 Feb 2009 20:52:59 -0500

> Thank you for trying to build the GNUstep port.  I've been holding
> these changes for far too long.

Thank you.  It looks right.
But I see that you already have 6 "tiny changes" installed, so this is
becoming significant.  We'll need you to sign copyright papers before we
can install this contribution.


        Stefan

Message #19 received at 2264 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 2264 <at> debbugs.gnu.org
Cc: Yavor Doganov <yavor <at> gnu.org>
Subject: Re: Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)
Date: Fri, 6 Mar 2009 17:38:48 +0200

Hi,

I've committed the fix to the typo in nsfns.m under my own name for  
now, until you can get your papers in.  (It was my typo, so I assume  
I'm allowed to fix it.  ;-)

Regarding the signal.h include in nsterm, can you provide some  
background or a mailing list archive link as to why it is needed?   
Should I put it under some #ifdefs, at least NS_IMPL_GNUSTEP but  
possibly more?

thanks,
Adrian

Message #24 received at 2264 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 2264 <at> debbugs.gnu.org, Yavor Doganov <yavor <at> gnu.org>
Subject: Re: Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)
Date: Fri, 06 Mar 2009 19:27:08 +0200

Adrian Robert wrote:
> 
> I've committed the fix to the typo in nsfns.m under my own name for
> now, until you can get your papers in.  (It was my typo, so I assume
> I'm allowed to fix it.  ;-)

Sure, thanks very much.

> Regarding the signal.h include in nsterm, can you provide some
> background or a mailing list archive link as to why it is needed?

This is where the signal names are defined on glibc-based systems:

,---- (libc)Standard Signals ----
| This section lists the names for various standard kinds of signals and
| describes what kind of event they mean.  Each signal name is a macro
| which stands for a positive integer--the "signal number" for that kind
| of signal.  Your programs should never make assumptions about the
| numeric code for a particular kind of signal, but rather refer to them
| always by the names defined here.  This is because the number for a
| given kind of signal can vary from system to system, but the meanings of
| the names are standardized and fairly uniform.
| 
|    The signal names are defined in the header file `signal.h'.
`----

> Should I put it under some #ifdefs, at least NS_IMPL_GNUSTEP but
> possibly more?

I'm fairly certain that this is needed on all GNU variants (I get the
same failure on GNU/kFreeBSD, for example).  However, GNUstep works on
other systems (*BSD, Solaris, etc.) so maybe there unistd.h is
sufficient (or not).  If it causes problems on MacOS, then of course
include it conditionally.

Maybe someone more knowledgable will be able to comment.

Message #29 received at 2264-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: 2264-done <at> debbugs.gnu.org
Subject: Re: Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)
Date: Fri, 6 Mar 2009 21:05:48 +0200

>
>> Regarding the signal.h include in nsterm, can you provide some
>> background or a mailing list archive link as to why it is needed?
>
> This is where the signal names are defined on glibc-based systems:

OK, thanks, this must be for the SIGTERM use in ns_term_shutdown.  On  
OS X it must already come in from somewhere, so including it will do  
no harm.  I'm checking it in.

You should still send the papers in though so we can use further  
stuff you come up with in the future.

;)

Message #34 received at 2264 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>, 2264 <at> debbugs.gnu.org
Subject: Re: Failed to build emacs 23.0.90 on Ubuntu 8.10 (x86_64)
Date: Fri, 06 Mar 2009 21:26:27 +0200

Adrian Robert wrote:
> OK, thanks, this must be for the SIGTERM use in ns_term_shutdown.

Exactly.

> I'm checking it in.

Thanks.

> You should still send the papers

I mailed back the signed papers to the FSF's office about a month ago.
It seems there are some communication problems between Boston and my
city, since their first letter got lost on the way.

Message #39 received at 2264 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: 2264 <at> debbugs.gnu.org
Subject: Re: 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.