Re: [Swarm-Support] Swarm on Leopard

[Marcus G. Daniels]

Gary Polhill wrote:
> my model compiles, but when I run it I get this error message:
>
> "Version 0 doesn't match runtime protocol version 2"
>   
I don't have Leopard, and there may be some minor changes now, but 
here's the gist of it:

Mac OS X has object code sections for Objective C classes, and with 
this, their executable loader can pre-initialize a bunch of Objective C 
data structures before the main of the program is even started.   For 
example, this loader knows about attaching protocols to objects and the 
physical structure of their classes.  Unfortunately, these things are 
different with the GNU runtime and Swarm is currently hardwired to 
aspects of the GNU runtime. 

The first that needs to be done is to defeat this loader.    The trick 
we've used before is a script in the toplevel of Swarm to wrap the 
assembler.  What it does is rename the sections to go unnoticed by the 
Apple loader (from __OBJC to __GNUOBJC) as they spew out from the 
compiler.    Last night I enabled this again, assuming that for now 
building Swarm will require a FSF compiler and the GNU runtime.   So if 
you do a checkout of the Swarm sources from CVS and put the latest 
automake/autoconf/libtool in a single install tree, and in your path, 
and then run `./autogen.sh', you should be good to go.

The error you see above is basically due to the fact that a GNU Object 
is different than an Apple Object, and that the Apple loader, believing 
that it has its native objects, goes ahead and steps on the GNU Object 
data structures in ways that don't work for it. 
> I tried compiling swarm with --disable-libobjc, and it choked at the last minute, 
> building the dynamic library, with a very long list of what looked to me like linker 
> messages. These complained of the lack of what looked like objc basics, e.g. 
> "__objc_class_name_Protocol". Is there a compiler/linker flag I should be using 
> to make sure Apple's native libobjc is picked up when building swarm (assuming that is 
> the problem)?
>   
No, just use the runtime in Swarm.  It has a few additional workarounds 
and features. 
And I just tested it.  Meanwhile, the SDG is investigating how to 
improve this situation.
> The other approach I had wondered about was building my own copy of gcc, rather 
> than using the gcc-4 that comes with the Mac. Any thoughts on whether this is 
> worth a try? I feel like this is tantalisingly close to working...
>   
Yeah, I just tested the latest (20080407) GCC trunk -- it works with 
Tiger.   This is i386, not x86_64.

Marcus