Re: My swarm compile for OSX

[Bill Northcott]

Hi Marc-Antoine

Very good work.  Thanks particularly for the nice full descriptions of 
what you have done.
It enables people to get things to work on their machines and get some 
testing done.

I will stick to getting the fixes into the cvs in appropriate ways.

> I used /swarm as prefix; the ar-gzip was built from /, so the command
> would be
> cd /
> tar -zxf ~/Desktop/swarm.tgz
> (or something similar, depends where you downloaded)
> setenv SWARMHOME  /swarm

I would advocate that we should be OS X consistent.  If it is a UNIX type 
build with bin,include,lib etc it should go either in one of /usr/local, 
/usr/local/swarm, $HOME/ or $HOME/swarm.  When we get to the point of 
bundling in a framework, the install should be /Library/Frameworks or 
$HOME/Library/Frameworks.  Putting stuff in the root directory is not nice 
- one of the many reasons that I don't like Fink.  Non-Apple stuff should 
be confined to /Library /usr/local and /Users.  That way Apple installers 
won't stuff it up and it won't break other software.

> This was built against (and probably requires) a recent FSF gcc
> somewhere in the path, Mac X11 beta, and fink versions of HDF5, BLT,
> and libpng.

With a bit of luck and a following wind you should be able to build swarm 
code against this library with the default compiler.  I was not having 
compiling errors with the Apple version, just crashes on some complex 
programs.  It is the same compiler code with a few speed ups.

> libtools from libtool-1.4.3

Hopefully this will be in the cvs by the end of the week.
libtool-1.4.3 also needs a SED environment variable which point to a 
recent GNU sed.  It seems you must of had one set up.  I will try to get 
this incorporated into the cvs.

> 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 would add that reordering the link command line does the job for me 
without the compiler build flag.
I am trying to avoid anything that is inconsistent with the Apple 
defaults.  That way as soon as Apple fix the crashes*, we can revert to 
their compiler and make life easier for everybody. (*Unless some other 
compiler hacker out there wants to have a go!)

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

Please see the README.MacOSX and INSTALL.MacOSX files.  The correct place 
for OBJCFLAGS is configure.in and libobjc/configure.in.  Then run 
autogen.sh, configure and make.  Or more simply open the PB project and 
build the targets autogen,config and swarmlibmake.  (Note Swarm is a 
composite target that does all three)  The rest of the configure 
instruction goes in macosx/swarmx/configure.sh 

> 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

The instruction issued by make is actually the one above that to invoke 
libtool.  Add lobjc and avcall to that.  It is a much shorter command!
I am trying to work out the right way to do this in the cvs.

> 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

Very helpful.  I had got as far as putting -lobjc up front, but not 
realised the culprit was -lgcc.

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

These problems will hopefully go away when we fix the cvs.  This will 
automagically correct Makefile.common, which is actually the problem in 
the tools directory.  The links to avcall in the src directory work OK.

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

avcall is assembler code, so the problem may be that your FSF gcc is using 
the GNU assembler rather than the Apple one.

> 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!

I suspect the problem is in your manual avcall linking.  avcall is linked 
in places other than the one you fixed.  So you probably have the broken 
avcall in other libraries unless you recompiled Swarm from scratch.  There 
should not be any inconsistency between the compilers that prevents 
linking.

Thanks again for all the good work.

Bill

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