Swarm on OSX status

[Marc-Antoine Parent]

Good day, all.

I think I am close to the same point as Bill:

Compiled everything with gcc3.3 fresh from CVS; I also used the  
libtools from libtool-1.4.3
My gcc was built with
../gcc-3.3/configure --prefix=/swarm --enable-languages=c,objc  
--enable-shared --enable-version-specific-runtime-libs

Note to Bill : I saw you were wondering about  
--enable-version-specific-runtime-libs: I ensures that the gcc libobjc  
is in $prefix/lib/gcc-lib/powerpc-apple-darwin6.3/3.3 instead of  
$prefix/lib, which avoids collisions with the swarm libobjc (I use the  
same prefix)

I build swarm with ../../../configure CC=gcc 'CFLAGS=-no-cpp-precomp  
-O3 -pipe' OBJCFLAGS=-fgnu-runtime --prefix=/swarm --without-jdkdir  
--with-bltdir=/sw --with-pngdir=/sw --with-hdf5dir=/sw

Note that the OBJCFLAGS did not carry into the libobjc/Makefile, I had  
to adjust this by hand, or I had a few spurious next compiles in  
libobjc.

After that, all seems to compiles fine until the tool directory; but  
there is a hidden problem.
I can compile the tool (I know you think this is a hack, but imho it  
promotes understanding of the issues ;-) with the following  command:

gcc -fgnu-runtime -o .libs/findImp findImp.o -L/sw/lib -L/usr/X11R6/lib  
-L../src/space/.libs -lspace -L../src/.libs -lswarm  
-L../src/analysis/.libs -lanalysis -L../src/simtoolsgui/.libs  
-lsimtoolsgui -L../src/simtools/.libs -lsimtools -L../src/random/.libs  
-lrandom -L../src/tkobjc/.libs -ltkobjc -L../src/tclobjc/.libs  
-ltclobjc -L../src/objectbase/.libs -lobjectbase  
-L../src/activity/.libs -lactivity -L../src/defobj/.libs -ldefobj  
-L../src/collections/.libs -lcollections -L../src/misc/.libs -lmisc  
-lBLT.2.4 -ltk8.4 -ltcl8.4 -lXpm -lpng -lhdf5 -lz -lX11 -lm -ldl  
../libobjc/.libs/libobjc.dylib -lgcc ../avcall/.libs/libavcall.al

I found out that having -lgcc come before libobjc was deadly, as it  
pulls in /usr/lib/libobjc.A.dylib somehow. This also leads me to find  
out that libswarm, which uses -lobjc in the same way, also pulls in the  
same library, as can be ascertained through
otool -L src/.libs/libswarm.dylib
So when you do whatever you do so libtool pulls the correct library for  
tools/findimp, also do it for libswarm.dylib. The same 'hacks' of  
putting ../libobjc/.libs/libobjc.dylib -lgcc explicitly in the  
compilation of libswarm solved my problem. (I now regret I cannot also  
put libavcall, as I now have to explicitly link it with everything I  
build! Another story.)

So... Again, I have a correct link of swarm. Does it run? No. I built  
the simpleSwarmBug (among others and swarm dies miserably of a bus  
error:
#0  0x003337d0 in -[Arguments_c parseKey:arg:] ()
#1  0x00003550 in __builtin_avcall ()
#2  0x00359f70 in objc_call ()
#3  0x0034dcfc in -[FCall_c performCall] ()
#4  0x003332b8 in parse_opt ()
#5  0x0012497c in parser_init ()
#6  0x00124244 in argp_parse ()
#7  0x0033407c in -[Arguments_c createEnd] ()
#8  0x00334314 in +[Arguments_c  
createArgc:Argv:appName:version:bugAddress:options:optionFunc:inhibitExe 
cutableSearchFlag:] ()
#9  0x00053ab0 in _initSwarm_ ()
#10 0x00002984 in main ()
#11 0x00002298 in _start (argc=1, argv=0xbffff5a4, envp=0xbffff5ac) at  
/SourceCache/Csu/Csu-45/crt.c:267
#12 0x00002118 in start ()

I started to suspect libavcall, so I ran the tests in avcall (make  
tests). Indeed it also dies in __builtin_avcall. So there is a bug in  
gcc3.3 as it stands...

I tried building the libavcall separately with the apple(december) gcc,  
and it passes the tests, but linking with that version of the avcall  
library did not improve my swarm performance otherwise. (same  
backtrace) I am sad to report... Though I did not expect much from this  
mix and matching of compilers, to be honest!

Anyway, hope my efforts give you a few hints...

Marc-Antoine Parent


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