MacOS X first results

[Marc-Antoine Parent]

Hello, folks. I tried to duplicate your results, to see whether I would 
get anything different. It seems I have.

Here is what I did:
I am using 10.2.3 with dec dev tools, the X11 from Apple, and Tcl/Tk, 
gperf, sed, HDF5 and BLT fresh from fink.
(I allow unstable packages in my setup)
(Bill, I know you don't like Fink, and indeed the autoconf/automake in 
fink kills the autogen phase. But that's a minor hindrance for me; I 
like the fact that everything else is push-button)

(BTW: I looked at compiling BLT against the Aqua Tcl/Tk... Let's say it 
won't be a drop-in.)

I also built the FSF gcc-3.2.1 compiler from scratch, with only a 
prefix and --enable-languages=objc to save time (Note in response to a 
comment from Bill: C is always included by default) I am using this 
only to compile swarm.

Then I build the (fresh from CVS) swarm, as indicated in the 
instructions in INSTALL.MacOSX.
As I mentioned, the autogen does not like fink tools; so I take fink 
from the path to do the autogen phase. Then I add back fink and the FSF 
gcc.

Then I can simply
../../../configure " 'CC=cc -no-cpp-precomp' --prefix=/swarm 
--without-jdkdir --with-bltdir=/sw --with-pngdir=/sw --with-hdf5dir=/sw

and make.
I got this interesting comment during make:
*** Warning: This library needs some functionality provided by -lgcc.
*** I have the capability to make that library automatically link in 
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

So I suspect I will have to redo the gcc with --enable-shared and 
possibly --enable-version-specific-runtime-libs

Another story... (Note I did reconfig and make with those flags; but 
the make was quite short, and did not start from scratch. Just in case 
this still changes someone's results.)

make succeeds for me on the libdefobj.a, which Bill reported as a 
stopper. (Maybe it's because he solved it in the CVS?)
I suspect using the up-to-date (fink) sed during the build process 
helps.

The last link in tools failed strangely, as he said:
cc -no-cpp-precomp -g -O2 -Wall -Wno-import -Wno-protocol -Wno-protocol 
-Wno-long-double -o .libs/findImp findImp.o
<...>
 -lobjc -lgcc -lBLT.2.4 -ltk8.4 -ltcl8.4 -lXpm -lpng -lhdf5 -lz -lX11 
-lm -ldl

complains about a lot of missing things, including all of libobjc calls.
If I add ../libobjc/.libs/libobjc.dylib by hand to the link command, 
all that's left undefined is
__i_Object_s__drop
___builtin_avcall

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.

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...)

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

Thanks to all who have been working on this so far.

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.