I just want to make clear that this error is NOT from Mac OS X, but rather pure Darwin on x86. I admit, I am not sure if this makes a difference for the error, but I felt it best to make this clear.
I am not a programmer, but I am very willing to test any changes or answer questions using my Darwin/x86 box.
-Ed Waldmire
waldmire at illinoisalumni dot org
<-----Original Message----->
From: David Ayers
Sent: 8/18/2003 3:24:37 AM
Subject: Re: Next release
Adam Fedor wrote:
> I plan on making another release of the core libraries in a few days.
> This will highlight the Header changes. Also, I may make this a
> pre-release version for the next stable release. If I do that, then
> I'll do two things:
Hello,
there seems to be an issue with configuring with the Apple runtime. I'm
not sure whether this is relevant for the release but it seems that the
configure script for base is generating:
checking ffi.h usability... no
checking ffi.h presence... no
checking for ffi.h... no
checking "for forwarding callback in runtime"... no
checking callback.h usability... yes
checking callback.h presence... yes
checking for callback.h... yes
checking "FFI library usage"... none
The intersting line is:
checking "for forwarding callback in runtime"... no
which is GNU Runtime specific test that probably sets enabled_ffcall to
'no'.
This seems correct as we probably don't want to configure for ffcall for
Apple's runtime, as there isn't a hook we can use.
Yet this also seems to lead to neither ffi nor ffcall being configured
and due to:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/configure.ac.diff?r1=1.13&r2=1.14&diff_format=h&sortby=date
we fail the configure (proably also for apple-apple-apple, ie. -baseadd
on OS X, where we don't need ffcall as we use Apple's DO).
I don't have a Darwin / OS X to really verify this and I'm kind of boged
down with other gcc issues that I can't look into it right now. So I'll
open a bug report.