Swarm 1.0.4 Installation Guide for Redhat Linux 5.0

[Paul E. Johnson]

Notes on Redhat 5.0 Install of Swarm 1.0.4
Paul Johnson (address@hidden)

As usual, to avoid grading papers and writing projects I decided to
install the new Redhat (5.0) and Swarm 1.0.4.  As usual, I screwed up a
bunch of stuff and had to cry a lot to SFI folks, who as usual were nice
enough to help me figure it out.  In case you find yourself with Redhat
5.0 and you want to run swarm 1.0.4, consider these advices I've cobbled
together, mostly from Marcus Daniels. 

If you are happy being a binary user, you can probably just go that route,
with the same install steps that are spelled out in the faq.  The one
exception that I found when I installed binary 1.0.3 was that some of the
include files in the Swarm /include directory clashed with the RH library
files and I had to try to make swarm several times, after each failure
removing one header file from Swarm-1.0.3/include.  Files such as time.h,
math.h, etc., had to go.  On a second install on another machine, I
circumvented this problem by changing a line in the Makefile.conf near the
bottom where the include files for Swarm were specified. I moved the
OTHERLIBDIR setting before the reference to the Swarm-103/include
directory, and it worked fine. Perhaps the binary version of Swarm 1.0.4,
which I have not seen yet, will avoid those problems. 

I am a big believer in the archive install because it builds character! 
And it builds a person's knowledge of their linux system. And the debugger
can step through the Swarm files.  Anyway, if you have swarm-1.0.4.tar.gz,
here is what you can do to complete an archive install. 

1. Redhat 5.0 uses tcl/tk 8.0.  It is OK to leave it where it is, because
many of the "new improved" RH features depend on it.  You can install the
older tcl/tk in the /usr/local hierarchy and direct swarm to use that.  I
went to the Sun systems ftp site and found tcltk-7.6p2.src.tar.gz, the
newest patched version of the source. When untarred/unzipped, it gives
subdirectories tcl7.6 and tk 4.2.  Inside each one, there are sources for
windows, unix, mac, and who the hell knows what else. 

After I screwed up installing this, I got specific advice from Marcus on
what to do. 
Install Tcl.  If you have the source unzipped, from the main directory go
like this: ($ is linux shell prompt)
 
  $ cd tcl7.6
  $ cd unix
  $ ./configure --prefix=/usr/local --enable-gcc --enable-shared
  $ make
  $ make install

and for Tk, get into the directory /tcltk4.2p/tcl7.6 and:

  $ cd unix
  $ ./configure --prefix=/usr/local --with-x --enable-gcc --enable-shared
--with-tcl=../../tcl7.6/unix
  $ make
  $ make install

The ./configure line gave me some trouble, but I believe this is correct.

Note, if you have something go wrong, before you try make again, type
"make clean" to get a fresh start.

2. Go to /usr/local/lib and make sure you see the tcl and tk libraries. 
You should see them, if you don't, you screwed up before.  Ordinarily,
you'd run ldconfig, possibly editing /etc/ld.so.conf to add the
/usr/local/lib directory and it would take care of making symlinks for
you.  It did not do it for me, so after runnign ldconfig I made sure I had
these links: 

lrwxrwxrwx   1 root     root           12 Dec 13 16:11 libtcl.so ->
libtcl7.6.so
lrwxrwxrwx   1 root     root           11 Dec 13 16:11 libtk.so ->
libtk4.2.so
If you don't have them, create by typing, for example, 
                $  ln -s libtk4.2.so libtk.so
My /usr/local/lib also has ".a" (nonshared) versions of the library
present because I did not understand about
the "enable-shared" option on the tcl/tk configuration when I did this for
the first time.  I don't think those
matter. The GCC HOWTO says the linker will always use an .so version
instead of an .a version if it is
available in the directory.

3. Get the new libtclobjc, which is called tclobjc-1.2.tar.gz. Unzip it
into  a directory (I have it in
/usr/src/tclobjc, for example).  Since RH has tcl/tk 8.0, you will be
screwed if you just do the regular
./configure.  The configure script finds the 8.0 stuff, and that dog don't
hunt, as they say in Texas. You
need to clue in tclobjc about which tcl/tk to use.  Change into the source
directory for tclobjc, type this:

$ TCL_LIBRARY=/usr/local/lib/tcl7.6 TK_LIBRARY=/usr/local/lib/tk4.2
./configure
$ make
$ make install

(NOTE: THE TCL.... configure bit is ALL ON ONE LINE)

That worked great, as evidenced by the fact that typing 
       $ make check 
produced a working test.  If your make check doesn't work, something is
wrong. (This is contrary to the advice
from previous versions of my FAQ, which said the make check won't work,
and don't worry about it!)

4. Install BLT 2.1 or BLT 2.3.  I still have the patched version of BLT
2.1--see the FAQ for more info about that if
you don't know already. There's one line in the source code you need to
fix.  Also, if you have a Pentium II PC, the
processor shows as a [686] and the BLT make will die an ugly death.   Go
into the blt2.1/cf subdirectory, open a file
called config.sub, and do global change of all [345] occurrences to
[3456].  After that, do the old  
      $./configure --prefix=/usr/local 
and tell it /usr/local/lib when it asks where you have tcl/tk). 
      $ make clean   (in case you have a previously botched make lying
around!) 
      $ make  
      $ make install

The test apps did fine too.  I did not mess with BLT 2.3 yet.

5. Remake swarm. It was a big nasty problem to make sure that swarmapps
did not try to use the wrong tcl/tk.  
I'm not sure I understand all the details, but I do know this: If you
adopt this new, radically-more detailed
method of configuring your Makefile.conf, you can succeed.  After I fouled
up lots of times, Marcus finally,
well, the equivalent of "just use this!"  My configuration options are
called "pj-UKANS-GNU/Linux-glibc2"
and in the top of Makefile.conf there is this:


# Select your setup here, set SETUP in the environment, or provide
# a value on the command line.
SETUP=pj-UKANS-GNU/Linux-glibc2
else
SETUP=$(SWARMSETUP)
endif

       ( AND THEN BELOW the SETUP=NONE segment (if you have any), is the
SETUP this refers to: )



ifeq ($(SETUP),pj-UKANS-GNU/Linux-glibc2)
SYS=GNU/Linux
CC=gcc
OPTFLAGS=-O3 -g
BLTPREFIX=/usr/local
BLTINC=$(BLTPREFIX)/include
BLTLIB=$(BLTPREFIX)/lib
XPREFIX=/usr/X11R6
XINC=$(XPREFIX)/include
XLIB=$(XPREFIX)/lib
TCLVERS=7.6
TKVERS=4.2
TCLPREFIX=/usr/local
TCLINC=$(TCLPREFIX)/include
TCLLIB=$(TCLPREFIX)/lib/tcl$(TCLVERS)
TKPREFIX=/usr/local
TKINC=$(TKPREFIX)/include
TKLIB=$(TKPREFIX)/lib/tk$(TKVERS)
TCLOBJCPREFIX=/usr/local
TCLOBJCINC=$(TCLOBJCPREFIX)/include
TCLOBJCLIB=$(TCLOBJCPREFIX)/lib
OTHERINCDIRS=-I$(TCLOBJCINC) -I$(BLTINC) -I$(TCLINC) -I$(TKINC) -I$(XINC)
OTHERLIBDIRS=-L$(BLTLIB) -L$(TCLOBJCLIB) -L$(TKLIB)/.. -L$(TCLLIB)/..
-L$(XLIB)
endif


Curious users will note that this is indeed radically detailed, compared
to the setup used until now.
It specifies the tcl/tk versions very clearly. Also note it does not have
the SYSDEPLIBS=-ldl line that
use to seem necessary.  And, nowhere does /usr/lib appear in the recipe.

If you don't follow this or some similar approach, you may compile swarm,
you may make applications, and
then they will crash with a vague message [tk extra] that happens because
your application--at runtime--
is accessing /usr/lib/libtcl8.0.so instead of /usr/local/lib/libtcl7.6.so.
After you compile an application,
you can check what it is going to grab by typing "ldd
executable-file-name".


6. Tryout a test application. Get the New HEATBUGS 1.0.1. If you don't,
you will get errors like this from make:

ObserverSwarm.m: In function `_c_ObserverSwarm__createBegin_':
ObserverSwarm.m:26: warning: `ProbeMap' does not respond to
`setProbedClass:'
ObserverSwarm.m:27: warning: `ProbeMap' does not respond to `createEnd'
ObserverSwarm.m:32: warning: `ProbeMap' does not respond to `addProbe:'

Both Marcus and Sven have tried to explain to me why the old notation has
changed. Instead of ProbeMap * probemap, we now want to use id <ProbeMap>
probemap.  If you are a programmer, you may know. If you are not, well,
the idea is to give the probemap object access to the protocols
collectively referred to as ProbeMap.  Here is the way Sven T put it: "the
deal is that 'Probemap * x' requires x to be an object of class Probemap,
while 'id <Probemap> x' allows x to be any kind of object that follows the
Probemap protocol (i.e. it implements all the methods required of that
protocol). Since in Swarm the create: methods are allowed to return
different objects depending on the parameters specified, the only way to
make sure you are getting an object with the right capabilities is to
specify the protocol. The Probemap class, if it even exists, may not
implement the Probemap protocol! Is the confusion total now?" 

I am just happy to have one less piece of old C pointer notation banging
around.

As usual, feel free to send questions, compliments, or additions.  Insults
can be addressed to my press
agent, address@hidden
Paul Johnson  address@hidden
12/16/97



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