HOWTO build Swarm and Swarm RPMS (was Re: [Swarm-Support] Swarm and gcc 3.x (and... suse)

[Paul E. Johnson]

Dear Claudio

Definitely you should build from a Swarm snapshot.  There are several 
changes that have been checked into CVS lately on Savannah, you might 
want to consider getting a fresh set and building.

If you start from scratch, you have to learn to build Swarm the usual 
way, and then translate that over to the RPM scripted build.  If your 
computer has a working RPM system, then it ought to be possible to take 
the SRPM file of a Swarm snap and rebuild it without fuss.  In what I 
describe below, it may sound like a hassle, but it is very satisfying 
once you understand the RPM system.  I have truly enjoyed packaging 
Swarm and other software too.  I'll try to get an SRPM for the newest 
Swarm snap and announce.  

I say "ought to be easy" because we've gone around and around with 
libtool and there is a big big problem with the relinking that occurs 
during the last part of the Swarm install that makes RPMS.  The libtool 
maintainers prefer to keep cross-platform uniformity, so they don't want 
to put things into libtool that accomodate systems that have relinking 
at install time.  If you have never built an RPM, this will perhaps not 
be understandable.  I'm not a computer scientists, just a hacker, so 
sometimes I don't use all the right words, so please bear with me. 
Anyway, when you build an RPM (in the proper way), it compiles the 
program and installs it, but it does not install it in /usr, rather, it 
installs it to a temporary place, usually in /var/tmp or such. That 
BUILDROOT directory is used because you don't want to pollute /usr with 
files from builds.  The libtool problem is that it gets confused because 
your install actually goes into /var/tmp/swarm but the final target (as 
specified by the prefix on the configure line) is really going to be 
/usr.  There is an error that says relinking failed because it could not 
find the swarm libraries in /usr/lib/swarm. Of course, it can't find 
them because they are not there, they are in 
/var/tmp/swarm/usr/lib/swarm.  The upshot seems to be that it is 
necessary to build Swarm and install it in the final "real place" /usr 
and then build an RPM that can find the files it needs in /usr when it 
tries to relink.  I've been doing Swarm RPMs a long time, I've been in 
the libtool list, and, believe it or not, there is no consistently 
workable alternative.  There have been several suggestions/workarounds 
along the way, various customizations of the ltmain.sh file, but I'm not 
expert enough on libtool to keep updating the customizations when 
libtool is re-released.  And the libtool team is not responsive on the 
issue.  Many RPM maintainers  from many distributions are confounded by 
this.  Recently I've read Debian developers are onto a fix, but don't 
know what it is.

I believe we Swarm folk are taking steps in the last week to work these 
problems out.  After recent changes that Marcus Daniels checked in, it 
is no longer necessary to use a specially patched gcc to compile the 
swarm source as distributed.  That's a good breakthrough. Further, no 
longer are the flags on the make command needed.  

So, it appears to me that, after I get the RPM and SRPM built for the 
new snapshot, then you can take the SRPM and try to rebuild on SUSE.  If 
you install an SRPM file, it gives you all the source code for Swarm and 
a SPEC file.  From there you can try rpmbuild.  I would urge you to 
build NOT AS ROOT.  If your user account "pauljohn"  (aren't all user 
accounts named  that? :) ) has a file ~/.rpmmacros like so:

%_topdir /home/pauljohn/LinuxDownloads/redhat

and then you make directories under /home/pauljohn/LinuxDownloads/redhat

mkdir -p /home/pauljohn/LinuxDownloads/redhat/SPECS
mkdir -p /home/pauljohn/LinuxDownloads/redhat/BUILD
mkdir -p /home/pauljohn/LinuxDownloads/redhat/SOURCES
mkdir -p /home/pauljohn/LinuxDownloads/redhat/SRPMS
mkdir -p /home/pauljohn/LinuxDownloads/redhat/RPMS/i386

That way, when you install SRPMS, their contents get dumped in there, 
and the compiling work is done in BUILD.  No root access is required to 
make RPMS this way.  In the SPECS directory, all you should need to do 
is type

rpmbuild -ba swarm-xxx.spec

If you get that far, the build will fail because of the libtool problem 
described above. However, if you change into the build directory, 
BUILD/swarm/=with-hdf, and become root, then you can try "make install" 
and it will actually write on your /usr partition. That installs a 
working version of swarm, and you should go ahead and test by compiling 
a swarmapp (set SWARMHOME=/usr in the environment). Get out of root to 
do that.  Then try again the rpmbuild command. WHen the compile gets 
along to the make install phase, the relinking will not fail because now 
libtool finds the libraries it needs.

I learned how to build RPMs by reading the free online book "Maximum 
RPM" from rpm.org.  Then practiced by taking SRPMS from other people 
trying to edit their SPEC files and rebuild their RPMS.  I recommend you 
take SRPMS for small, simple projects. Don't pick a massive, heavily 
customized example like gcc.  I recall the SRPMs for some dock apps like 
"mountapp" were simple and clear. (http://mountapp.sourceforge.net/). 
The SRPM for WindowMaker was written by a friend of mine and it 
exercises pretty many of the muscles without being too complicated. I 
think it took  only a couple of days to understand the philosophy and 
practice of RPM, (and then much longer to understand that problem with 
libtool).

Next, concerning your gcc question, it appears to me that no gcc after 
3.0.4 is completely right.  3.2 introduces a set of problems about 
casting of objects that cause warnings to be issued.  On the other hand, 
these were fixed in the snapshots of 3.3 from last September, but then 
other problems have reappeared.  THe one that I've been using, gcc 
-2002-09-09 can compile swarm, but it has a really interesting bug that 
my students discovered.  if you do this:

id x;
x = [whatever];
id y;
y = [whatever];

the compiler 2002-09-09 does not give the usual error, but rather the 
compile finishes without error/warning and then there is a runtime crash 
because the object y is never created.

We have until lately insisted that Swarm compile with the flag set so 
that warnings are treated as errors.  That's -Werror in the gcc line. 
Lately I gather that people using gcc-3.2 are able to compile Swarm if 
they ignore the warnings.  So I'm going to look into that and see what 
happens.  If I succeed, I'll post RPMS and SRPMS you can get and I'll 
announce here.  I'll turn off the -Werror option with a patch and then 
I'll try to build Swarm with gcc-3.2.

I hope this helps. truly, and also truly hope you will continue with 
your offer to make RPMs for Slackware.  You will be proud of your effort 
if you stick to it and get the job done. You can feel free to contact me 
directly if you have questions: pauljohn at ku.edu.

pj


Claudio Tessone wrote:

> Hi!
>
>        I begun to play on agent based models, and, as other people in 
> the list was glad of discovering swarm (it will also make me 
> rediscover Objective C). I also read in previous messages on the list 
> that there are some people that tried to compile swarm on suse but it 
> is not possible for the recent development snapshots on recent 
> distributions. I would like to contribute a litle bit to those who 
> want to work with swarm on suse (even I would try to generate the 
> RPMs) but I would like to receive some instructions to work on that.
>
>         First of all, do you recommend me to work with the stable 
> release, or should I try the snapshots??? what are the differences???
>
>         Can you tell me if there is everything ok with gcc -v >= 3.2?
>
>         Thanks in advance,


--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700