Custom Query (1030 matches)

In the course of rebuilding the interface headers, I got an ICE on Debian unstable on an i386 system. This error does not show up on Debian squeeze (stable).

This corresponds to the file x86-headers/gnome2/C/populate.sh in the sources, whose content is

################################################## #!/bin/sh CFLAGS="-m32"; export CFLAGS h-to-ffi.sh pkg-config --cflags libgnomeui-2.0 /usr/include/libgnomeui-2.0/gnome.h ##################################################

The error is:

In file included from /usr/include/libgnomeui-2.0/libgnomeui/libgnomeui.h:34, from /usr/include/libgnomeui-2.0/gnome.h:7: /usr/include/libgnomeui-2.0/libgnomeui/gnome-app.h:58: internal compiler error: Segmentation fault

I have therefore disabled the building of the ffi for this header. I don't get any errors for the other headers.

I have no idea what information would be useful or relevant, so let me know what information you need.

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

If I locally revert the change that disabled armv6 support in lisp-kernel/linuxarm, it still appears to work. (I haven’t tried the test suite at all though.)

Since there are tons of original Raspberry Pi devices out there that are armv6, it might be worthwhile to keep armv6 running. For one thing, it might be easier to use for people who want to do GPIO stuff from Lisp; while I was doing it on an Intel Edison, not a Raspberry Pi, I could never make my Lisp bridge to libmraa actually work under SBCL, whereas it just worked immediately under CCL.