[Openmcl-devel] Building on a G5

[Gary Byers]

On Thu, 7 Apr 2005, flip phillips wrote:

> On Apr 7, 2005, at 5:49 PM, Gary Byers wrote:
>
> > On Thu, 7 Apr 2005, flip phillips wrote:
> >
> > If anyone was using Tiger pre-releases, I hope that they wouldn't
> > discuss them publicly and violate their NDAs.  (Seriously.)
>
> Of course, but there are legitimate, Apple sanctioned Tiger
> developers, myself included, and it is public knowledge that Tiger
> exists, people have it, and that folks are developing for it. I
> merely am probing to see if anyone has OpenMCL working under it and
> would like to correspond. (privately is fine, and I respect your
> position, esp seeing as Apple has been a little trigger happy lately)

Privately then: 0.14.3 (the released and -dev versions) should run
fine under Tiger, with the unfortunate exception of the Cocoa demo.

>
> Now- as for Hemlock / the IDE, compiles fine, but subsequent loading
> of 'cocoa':
>
> ? (require "COCOA")
> Unhandled exception 11 at 0x90000c18, context->regs at #xbfffe718
> Read operation to unmapped address 0x0000000c
> In foreign code at address 0x90000c18
>

Was this under Tiger or Panther ?  (I don't think that things even
get that far under Tiger; GCC 4.0 encodes ObjC types a little differently,
and the Cocoa bridge has difficulty making sense out of some things.)

Things -should- work under Panther; the address above looks like
something may be trying to send a message to a non-object.

> which looks a little nastier. is this possibly related to the foreign-
> function database? I haven't had the time/guts to play with ffigen
> yet (which I am presuming generates the catalogs?)

ObjC methods and instance variables have "type strings" associated
with them; a method parameter or ivar whose type string is "i" is
of type "int", for instance.  Once we get beyond "i is for int", it
starts to get a lot more complicated, and the cocoa bridge has difficulty
parsing some of the encodings produced by GCC 4.0.

Even if/when this parsing works, it's slow, and the good news and the
bad news is that it provides an incredibly detailed model of how every
class and method in the Cocoa libraries is implemented (including lots
of internal classes and methods whose implementation may change in
minor ways between dot releases.  If a saved image runs in a slightly
different OS release than it was saved from, some of the details
(probably unimportant, obscure, internal details) of its model may be
inaccurate.  The bridge has no idea what's "important" or "obscure" or
"internal", so rather than parsing all of the type strings again and
trying to reconcile its model with reality, it gives up.  (That's not
the only thing that it could do, but it's not entirely unreasonable,
either.)

Another approach to all of this (and one which seems to offer other
advantages) is to make the interface translator retain ObjC
information and to have the Cocoa bridge use that information to build
its model of things: the published interface to Cocoa is a good deal
less volatile than the actual implementation, and any differences
between that model and reality (generally, classes/methods that are
expected to exist not being found in the libaries) can be handled more
tractably ("you're trying to run a program compiled with Tiger
interfaces under Panther; you may get errors if you try to instantiate
or subclass those classes or define methods on them.")

OpenMCL's interface translator (ffigen) is cracking at the seams; the
released version still depends on the GCC 2.95 preprocessor.  Helmut
Eller did some work last summer to get it to work with GCC 3.x, and
I've been working on getting something that includes Helmut's changes
to generate ObjC class and method information.  I hope to be able to
base that on (a recent prelease of) GCC 4.0, and hope to have a at least
a test version of that available soon.  (The GCC 3.x version seems to
be pretty solid; I don't trust the GCC 4 version as much yet, but there
are some obvious potential advantages - to G5 users, especially - in
trying to get a GCC 4.x-based version working on Darwin.)

Once that's done, there's some more work involved in getting the ObjC
bridge to use this information (instead of relying entirely on
introspection as it currently does.)  I -think- that it makes more
sense to work on that than it does to put a lot of effort into trying
to fix the type-string parser (though the fixes involved probably aren't
too complicated.)

>
> --
> flip phillips, phd
> http://www.skidmore.edu/~flip
>
>