Re: [Swarm-Support] Installing under Gentoo Linux

[Bill Northcott]

I don't use Swarm on Linux, but I do package up binaries for MacOS X.

I would like to respond to the remarks below.  We are conscious of the  
deficiencies in the Swarm documentation which tend to lead people up  
many blind alleys.  We are trying to build a new and more helpful web  
site at
http://wiki.swarm.org.  However, Swarm no longer has any official  
funding.  So everything has to be done by volunteers.  We all have a  
living to earn and usually research to get done.  If anyone is able to  
help with coding, testing, debugging, documentation or the website  
please let us know.

I write the following in the hope that it explains why Carlos had the  
problems he did and will help others to avoid them.

On 15/04/2004, at 3:12 PM, Carlos Castillo wrote:
> I've been trying to install Swarm (cvs) under Gentoo Linux for a  
> couple of
> days now, and I have more or less succeeded, however I'm having  
> problems
> getting an application to work. Some developers and/or users might  
> find this
> information useful.
>
> Here's what I have done and the issues I've had to deal with:
>
> -Installed the required software (blt2, libpng, xpm, hdf5, zlib,  
> libffi,
> kaffe, etc). Verified the software worked correctly. Note that there  
> is not
> a list of packages needed for the development version available at the  
> web
> page, I used the list of software available at the stable version page.

The business of required packages is non-trivial particularly on Linux.  
 All Linux distributions are different and installers have many options  
about what is and is not included.  Hence it is very hard to provide a  
definitive list of what is needed on Linux.  On MacOS X, for instance,  
it is much easier because the system is more standard.

For guidance
Required:
gcc at least version 3.0.x for preference 3.3.x or even 3.4 when it is  
released.  Avoid 3.2.x on most systems.
Tcl, Tk xpm and BLT are required for the graphical display.
zlib is required but already included on most modern systems.
Some foreign function library (ffcall or libffi) is required.  However,  
a version of avcall which is
part of a ffcall is now included in the sources, and will be used if  
nothing else is specified to configure.
Libffi is now part of gcc and will not need to be separately installed  
with a recent version of gcc.  It is likely that we will move to using  
libffi exclusively in the future because it should be better supported  
as part of gcc.

Optional packages:
If you want to use the Java API you need to have either some version of  
the Sun JDK or the opensource Kaffe, but not both.

If you want to use png graphics, you need libpng.

If you wish to use HDF5 archiving, you need libhdf5.  Without it, Lisp  
archiving will be used.

> -Checked out the cvs version after trying the latest stable and failing
> miserably to install it on a reasonably current Linux system.
>
> -./autogen.sh, generates some syntax errors in the configure script, I  
> just
> deleted the problem areas and all went well

The 'latest stable' or version 2.1.1 will NOT build on any modern  
system.

The CVS checkout is only intended for those with a good understanding  
of the GNU autoconf/automake/libtool suite.  Autogen.sh is just a  
simple driver script for them.  It is expected that it has to be  
modified for particular systems.

Can you please explain what you mean by 'syntax errors in the configure  
script'?  A configure script runs very many small test programs.  Some  
of these test programs will give syntax errors.  That is normal.

All autogen.sh does is invoke the GNU autotools.  Errors in a configure  
script are either caused by problems in the autoconf/automake  
installation on your system or incompatabilities between it and the  
code in Swarm.  The GNU autotools are frequently updated which is why  
the CVS code is not suitable for most users

Paul Johnson makes recent source code packages, which do not require  
autoconf and friends, available on his site:
http://lark.cc.ku.edu/~pauljohn/Swarm
You can also find there an excellent FAQ.  His latest source tarball:
http://lark.cc.ku.edu/~pauljohn/Swarm/Swarm-2.2X_Fdr1/swarm 
-2.1.150.20040413.tar.gz
Is from the cvs just two days ago.

Using these will avoid all the issues with autotools.   There are also  
binary rpms there for Linux and links to binaries for Windows and MacOS  
X.

> -./configure had problems working with kaffe (which I later came to  
> know
> was no longer required, but it wasn't mentioned explicitly anywhere), I
> switched to sun-jdk and all went better.
>
> -make initially failed in the tools directory, where I had to compile a
> couple of source files manually because of missing headers, it couldn't
> find some required headers. Unless up to this point I have done  
> something
> wrong, everyone compiling the development version should be running  
> into
> this problem.

A number of header files and other sources are built by the configure  
script.  If you have modified the configure script that would explain  
why they do not build.  Some other sources such as those for Java and  
COM are built by LISP programs invoked by the makefiles when  
appropriately configured.
Without those headers and auxiliary files, you cannot build working  
code.  So I will ignore most subsequent problems.

If you think you have trouble with a configure script, please report it  
here.  So we can fix the code that produced the script.  Do not try to  
modify the scripts yourself.  They are too complex and you will just  
waste your time.

> install, but I don't think so. Tweaked the makefile. It compiled but
> it didn't run. I had to go to the directory where blt was installed  
> and to a
> symlink from bltGraph.tcl to graph.tcl (I'm using the latest stable of  
> BLT).

This is a pain.  The name of the file was changed in BLT but not  
documented.  If someone can tell us the BLT version at which the change  
was made, we can fix it in configure.  If we fix it unconditionally it  
will break on older versions of BLT :-(

> under linux, does the COM directory have to be built?

COM is only meaningful on Windows.  So it does not build on other  
platforms.
>

Hope this helps.
Bill Northcott