Re: [Swarm-Support] Swarm on Leopard

[Gary Polhill]

Thanks Marcus, but we're still not there... I now get (when running my model)

"Version -1607261952 doesn't match runtime protocol version 2"

I suppose that's progress of a sort.... :-)

I used gcc-4.2.2, libtool-2.2.2, automake-1.10.1 and autoconf-2.68 

I'm using a Macbook; I don't think that's 64 bit.

I also tried Bill's OSX 10.4 packages as suggested by Alessandro, but no joy 
there either (the libobjc problem again--long list from the linker of unmatched 
symbols when using Mac's gcc). Would the lack of Xcode explain this--I've been 
trying to avoid it...?

>>> "Marcus G. Daniels" <address@hidden> 04/07/08 3:06 PM >>>
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
_______________________________________________
Support mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/support


-- 
Please note that the views expressed in this e-mail are those of the
sender and do not necessarily represent the views of the Macaulay
Institute. This email and any attachments are confidential and are
intended solely for the use of the recipient(s) to whom they are
addressed. If you are not the intended recipient, you should not read,
copy, disclose or rely on any information contained in this e-mail, and
we would ask you to contact the sender immediately and delete the email
from your system. Thank you.
Macaulay Institute and Associated Companies, Macaulay Drive,
Craigiebuckler, Aberdeen, AB15 8QH.