patch for fixing amd64 build failure for gnustep header

[faheem]

Hi,

See patch below, which follows the Debian DEP3 standard.

I think the information in the patch description is mostly sufficient to explain the issue. It is possible this build issue is specific to Debian and not a problem elsewhere. It is also possible that this additional flag will break builds on other platforms. I cannot test either of these possibilities easily. In any case, I'm forwarding this patch upstream, as per Debian guidelines. If this patch is included upstream, then it will not need to be included in Debian.

Please also note that the x86-headers64 used was from

 svn://svn.clozure.com/openmcl/release/1.8/x86-headers64

The corresponding web link is

 http://svn.clozure.com/publicsvn/openmcl/release/1.8/x86-headers64/gnustep/C/populate.sh

BTW, I notice that the interface databases are only built for the gnustep headers on amd64. I tried copying them to i386 and building the databases on i386, but got a segfault.

Description: Fix error when running x86-headers64/gnustep/C/populate.sh
Without this patch, when running x86-headers64/gnustep/C/populate.sh,
the following error occurs.
.
  In file included from
  /usr/include/GNUstep/Foundation/NSClassDescription.h:30, from
  /usr/include/GNUstep/Foundation/Foundation.h:49, from
  /usr/include/GNUstep/Cocoa/Cocoa.h:33, from
  /tmp/Cocoa.h.tmp_8LoKm:1:
  /usr/include/GNUstep/Foundation/NSException.h:42:2: error: #error
  The current setting for native-objc-exceptions does not match that
  of gnustep-base ... please correct this.
.
Reference: In [Compile Objective-C Programs Using gcc]
(http://blog.lyxite.com/2008/01/compile-objective-c-programs-using-gcc.html)
there is the following:
.
  Also note that if you did not include -D_NATIVE_OBJC_EXCEPTIONS, you may run into the following error:
.
  /usr/include/GNUstep/Foundation/NSException.h:42:2: error: #error The
  current setting for native-objc-exceptions does not match that of
  gnustep-base ... please correct this.
Author: Faheem Mitha
Bug: <URL to the upstream bug report if any, implies patch has been forwarded, optional>
Forwarded: <URL|no|not-needed, useless if you have a Bug field, optional>
Applied-Upstream: <version|URL|commit, identifies patches merged upstream, optional>
Last-Update: Mon Feb  4 2013
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
diff -r b9b89814e0e0 -r 2b8f5332445e x86-headers64/gnustep/C/populate.sh
--- a/x86-headers64/gnustep/C/populate.sh       Sun Feb 03 13:15:57 2013 -0500
+++ b/x86-headers64/gnustep/C/populate.sh       Sun Feb 03 13:57:12 2013 -0500
@@ -1,2 +1,2 @@
 #!/bin/sh
-h-to-ffi.sh -m64 -I/usr/include/GNUstep /usr/include/GNUstep/Cocoa/Cocoa.h
+h-to-ffi.sh -m64 -D_NATIVE_OBJC_EXCEPTIONS -I/usr/include/GNUstep /usr/include/GNUstep/Cocoa/Cocoa.h

[rme]

I'll apply your patch, at least to the trunk.

On the other hand, the Objective-C bridge doesn't current work with GNUstep, so it may make more sense not to try to build the gnustep headers at all. We leave them in there in case we or someone else get inspired to revive support for them, but they're not otherwise useful or necessary.

[faheem]

Hi, Thanks for the reply.

On Tue, 5 Feb 2013, Clozure CL wrote:

#1057: patch for fixing amd64 build failure for gnustep header ----------------------------------------+----------------------------------- Reporter: faheem | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Foreign Function Interface | Version: trunk Keywords: | ----------------------------------------+-----------------------------------

Comment(by rme):

I'll apply your patch, at least to the trunk.

On the other hand, the Objective-C bridge doesn't current work with GNUstep, so it may make more sense not to try to build the gnustep headers at all. We leave them in there in case we or someone else get inspired to revive support for them, but they're not otherwise useful or necessary.

Is there any harm in leaving this enabled in Debian? If not, then I would be inclined to do so, rather than disabling it, including an explanation, etc. Can you give me a url for the commit? Then I can add it to the patch. Also, will this patch end up in  svn://svn.clozure.com/openmcl/release/1.9/x86-headers64?

Regards, Faheem

[faheem]

It looks like I will have to disable this after all. On amd64 unstable, I get the following. On stable it builds fine. I haven't tried to investigate what the problem is, since it is not used anyway.

I'll just delete that directory (/x86-headers64/gnustep) from the tarball.

? +++ /usr/include/GNUstep/Cocoa/Cocoa.h
In file included from /usr/include/GNUstep/Foundation/NSObjCRuntime.h:86,
                 from /usr/include/GNUstep/Foundation/NSObject.h:30,
                 from /usr/include/GNUstep/Foundation/FoundationErrors.h:29,
                 from /usr/include/GNUstep/Foundation/Foundation.h:33,
                 from /usr/include/GNUstep/Cocoa/Cocoa.h:33,
                 from /«BUILDDIR»/ccl1.8+svn15682/debian/tmp/tmp/Cocoa.h.tmp_y4ji2:1:
/usr/include/GNUstep/GNUstepBase/GSObjCRuntime.h:345: error: parse error before 
'GSIVar'
/usr/include/GNUstep/GNUstepBase/GSObjCRuntime.h:376: error: parse error before 'GSCGetInstanceVariableDefinition'
/usr/include/GNUstep/GNUstepBase/GSObjCRuntime.h:382: error: parse error before 'GSObjCGetInstanceVariableDefinition'
Need to create info for type:
 <real_type 0x2b7b2aecf820 NSTimeInterval DF
    size <integer_cst 0x2b7b2a6aec30 type <integer_type 0x2b7b2a6b45b0 bit_size_type> constant invariant 64>
    unit size <integer_cst 0x2b7b2a6aec60 type <integer_type 0x2b7b2a6b44e0 long unsigned int> constant invariant 8>
    align 64 symtab 1000 alias set -1 precision 64>
/usr/include/GNUstep/Foundation/NSDate.h:117: confused by earlier errors, bailing out

[rme]

Not including it is probably best. I'll close this ticket.