[Openmcl-devel] ffigen progress

[Gary Byers]

On Thu, 26 Feb 2009, james anderson wrote:

> hello;
>
> i have made some progress translating the open-mpi interface.
> sufficient, that it may be worthwhile to record a few observations.
>
> On 2009-02-25, at 04:03 , Gary Byers wrote:
>
>> This is a mess; there should be a wiki page explaining this.
>
> that would be nice. it was more than five years ago, the last time i
> did this - with mcl, but i recall a similarly tentative process.
>
>>
>> The easiest way to obtain a version of ffigen that works (on most
>> platforms;
>> see below)  is to build it yourself from svn.
>>
>> For most platforms, you can do:
>>
>> [... useful things ...]
>
> i followed these instructions. as my "gcc --version" yielded 'build
> 5370', i used the trunk sources.
> they did work, but it was important to follow them literally, in that
> the "4.0.0" sources were required, even though my gcc is actually
> "4.0.1".

What do you think the installed version of gcc (that you use to build
some version of the translator) has to do with anything ?

Please follow the instructions for building the Apple-specific branch.

You can generally use the 4.0.0/trunk version on a Tiger system
(that's what we all did in ... 2005 or so.) You might even be able to parse
some Leopard headers with that version, but that'd be sort of a pleasant
surprise.  (The version of GCC that Apple called 4.0.1 when it was
released with Leopard was radically different from 4.0.0.  If there
was an FSF 4.0.1 release, it's very different from what Apple calls
"4.0.1".)

In yesterday's email, I said that the basic difference between the
4.0.0/trunk version and the Apple-gcc-5465 branch had to do with the
latter's support for ObjC 2.0 extensions.  That's clearly not the
only difference, and the Wiki page at 
<http://trac.clozure.com/openmcl/wiki/BuildFFIGEN> hopefully explains
this a bit more clearly.  (If that was


If you installed a Tiger-era version (2.x, IIRC) of the XCode tools
on a Leopard system (assuming that nothing stops you from doing so),
but were able to retain the Leopard headers, you'd likely encounter
lots of difficulty trying to compile C code.  That wouldn't be too
surprising and the details wouldn't be very interesting, and that's
very similar to what you're doing.

If I'd said "using the trunk/4.0.0 version on Leopard isn't supported",
that might have been overly restrictive but less confusing, and might
have wasted less of your time and mine.

As for some of your other observations: you're correct in noting that
it's often difficult to tell what library or libraries define the
functionality declared in a particular set of header files, and it's
also often (too) difficult to tell what other files/#defines/options a
particular header file implicitly depends on.  I don't mean to sound
too cynical about it but it's a crazy, mixed up world, and I don't
know anyone who's thought about either of these things at all without
reaching that conclusion.