Re: My swarm compile for OSX

[Marc-Antoine Parent]

> Very good work.  Thanks particularly for the nice full descriptions of
> what you have done.

My pleasure. Would not have got to the finish without everybody's work 
before.

> It enables people to get things to work on their machines and get some
> testing done.

Alex is working on it :-)

I have compiled and run a lot of swarm programs now; so far so good, 
with the exception of heatbugs, for some reason.
Will look into it later.

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

Oh, of course! I do realize I'm hacking through to solutions in _some_ 
cases ;-)
I was interested in getting a running system I guess. But I know the 
work is not over.


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

You are of course correct. It was my intent to do so; only I had put 
Alex's build in /usr/local/swarm.
I  am rebuilding with that prefix right now, the tar gzip will be 
updated very shortly. OK, done...

> When we get to the point of
> bundling in a framework, the install should be /Library/Frameworks or
> $HOME/Library/Frameworks.

Yes, that is another piece of work. Making it a framework would be nice.
Though I must say, much as I love the framework idea for encapsulation, 
I hate the way that any code that uses the framework must use the 
framework name as a prefix in the include directives! Changing the 
Makefiles to use the -framework flag is easy enough, but changing the 
source code to adjust to the Apple syntax is a major thorn in the 
backside. Think that all Swarm programmers will have to add an #if 
darwin to all their code... What is Apple thinking? Anyway, sorry for 
the little rant.

> Putting stuff in the root directory is not nice
> - one of the many reasons that I don't like Fink.

It's quite well circumscribed, actually. And close to being standard on 
the platform. Do I understand you won't favor a fink install of swarm? 
;-)

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

I tried to compile a few apps with the apple compiler. No go :-(
Also, I said in my email "a recent FSF gcc"; we determined with Alex 
that it _has_ to be the 3.3 stream. Forget 3.2, as you said.


> > libtools from libtool-1.4.3

I am not honestly sure this is necesssary, BTW. I added it because you 
were considering it. But my new make-in-progress seems happy without 
it. Yes, all is fine with the CVS version. Oh, but it does introduce 
-lavcall itself! I wonder what changed.

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

Yup. Fink sed and gperf and libdl...

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

By collision, I mean overwrite. If I use the same prefix for gcc and 
swarm, swarm will overwrite gcc's libobjc because that one will be in 
$prefix/lib unless we specify --enable-version-specific-runtime-libs.
I understand you try to be apple compatible, but as long as we're not 
using the apple gcc, we can have safer variants; as for when we do use 
the apple gcc, it won't matter since we won't use the prefix /usr to 
build swarm, and no conflict will be possible.

> I would add that reordering the link command line does the job for me
> without the compiler build flag.

Same here, except that as I said the install can then clobber the gcc 
libobjc...

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

OK... It's just that I am not that familiar with configure.in, and 
avoid touching it when I can. Pardon my ignorance in that domain. I'd 
be happy if you added the flags in the right places now that I 
determined that they are needed ;-)

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

Yes, I am using this now:
/bin/sh ../libtool --mode=link gcc  -fgnu-runtime -o findImp -L../src 
findImp.lo -lswarm ../libobjc/.libs/libobjc.dylib -lgcc -lavcall
Oh, -lavcall is added automatically, but not the appropriate -L... So 
now it's
/bin/sh ../libtool --mode=link gcc -fgnu-runtime -o findImp -L../src 
findImp.lo -lswarm ../libobjc/.libs/libobjc.dylib -lgcc 
-L../avcall/.libs

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

Yah... As I said it seems to work now? I suspect reverting to the 
libtool did the trick.

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

OK. This is really puzzling. The avcall that works is the one Alex 
built using gcc 3.2.1 (If I'm not mistaken.)
Alex, had you built the gnu as, ld tools at the same occasion?
My avcall (using gnu 3.3) fails its own tests; should we report this to 
avcall, gcc or both, you think?
And building avcall with the Apple compiler passes its own tests but 
does not work with the rest of the swarm code.
AFAIK, the same assembler is used throughout, no? I mean unless the gcc 
build also builds the assembler at the same time?

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

I am quite sure this is not the case, as (when I was making those 
tests, i.e. before the avcall problem fixed itself >:-( ...) any link 
would fail, complaining avcall was missing. So I am quite sure avcall 
was just absent from everything. Also, putting Alex's library in place 
of mine would fix swarm executables without a relink.

> Thanks again for all the good work.

We'll get there ;-)

For me, the most urgent is adding my three sourcecode fixes to the CVS:
a) The dispatchless drop code in DefObject.m
b) The blt library rename in src/tkobjc/TkExtra.m (we should ifdef that 
with a BLT version number I suppose. I wish I knew when that 
happened...)
c) Prevent the duplication of nil_method between libobjc/nil_method.c 
and src/defobj/internal.m

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.