Re: MacOS X first results

[Marc-Antoine Parent]

> I got this far, after I changed the name of libobjc to get it to link.
>
> > So for me, avcall is missing rather than overdefined.
> > Again, I may add ../avcall/.libs/libavcall.al by hand to the link
> > command: All that's missing then is __i_Object_s__drop.
>
> Let's fix the problems not kluge around them.  There seem to be 
> problems
> with the libtool in Swarm on MacOS X.  When I have rebuilt everything
> against Apple's X11, I will try updating it to the current 1.4.3 
> verson.

Well, maybe we should have a look at the fink version of libtool ;-)
I felt I was too close to a solution, and I wanted to see how close 
exactly. That allowed me to go one step further, and see the next bug.

> > The story of that one is annoying: The __i_Object_s__drop is used
> > directly in DefObject.m, at line 348:
> > _i_Object_s__drop (self, M(drop));
> > but the name mangling scheme changed, and that code is now obsolete.
> > I think the following may work as a replacement:
> >    void (*dropper)(id, SEL) = (void (*) (id, SEL)) [Object
> > methodForSelector:@selector(drop)];
> >    dropper(self, M(drop));
> > (But my grasp on ObjC is shaky, correct me if this is a blunder...)
>
> Do you use Project Builder?  It really is very helpful.  When you had
> found _i_Object_s__drop (self, M(drop)) in DefObject.m, all you had to 
> was
> select the text, go to 'Find>Batch Find Selected Text' in the menu 
> bar. In
> a few seconds, because all the code is indexed, you would have seen 
> this -
> macro.h:18
> #define DROP(obj) _i_Object_s__drop (obj, M(drop)) .
>
> This macro is conditional on #ifdef METHOD_FUNCTIONS.  Clearly l:348 in
> DefObject.m should be
> DROP(self);
> and probably macros.h l:18 should be deleted and l:26 (#define 
> DROP(obj)
> [obj drop]) should be unconditional.  I will check with the others and 
> fix
> the cvs.
>
> Then the problem is fixed not kluged.
>
> If Paul is reading this, do we get the error on x86 builds with
> METHOD_FUNCTIONS.

Arhem. Point taken on the search, but it seemed clear to me that the 
intent of the drop as it stands in DefObject.m, line 348 was to bypass 
dispatch (why is obscure to me, however.) There is even a comment to 
that effect. Using DROP(self) as you propose clearly reinstates the 
dispatch, and could lead to new problems, no?

My code was a way to do a dispatchless drop. Maybe we need another 
macro for that call, and certainly I think that the
void (*dropper)(id, SEL) = (void (*) (id, SEL)) [Object 
methodForSelector:@selector(drop)];
should be abstracted out in some static startup code for efficiency, so 
my solution was temporary, but please give me some credit for it not 
being totally unthoughtful...

> > That solves my problem and I now have a compiled, installed swarm. 
> > Will
> > test soon. ;-)
>
> Well done.

I'm afraid not, after all. The reason I could compile is that gcc was 
implicitly compiling for next-runtime, i.e. using _objc_msgSend (à la 
Apple) instead of objc_msg_lookup used in the swarm objective C.
So nothing links in the end.

Trying to configure swarm so -fgnu-runtime is in the CFLAGS breaks 
compilation (in predicates)...
So maybe I should follow your advice and try with a more recent gcc. 
Will keep you updated.

Marc-Antoine

                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.