Swarm Installation report (Linux-FT)

[Barry McMullin]

I've just been through the process of installing Swarm
(961020) on my Linux (FT Rev 1.2, on a G2K Pentium
Pro box).  It wasn't *too* bad - about a day's work -
but there again, this was my second time around, so
I had a fair idea what I was looking out for.  Anyway,
in case it may be helpful to anyone else, here's
some notes on the process.  It's fairly specific to
linux, and even the FT distribution - but it might give
some useful ideas for other platforms also.


1: Prequisite Programs:
=======================

Linux-FT 1.2 came with gcc, GNU make, and gdb installed:

  $ gcc --version
  2.7.2
  $ make --version
  GNU Make version 3.74, by Richard Stallman and Roland McGrath.
  $ gdb --version
  GDB 4.15.1 (i486-unknown-linux), 
    Copyright 1995 Free Software Foundation, Inc.

so that's all fine...



2: Prerequisite Libs:
=====================

This is the most fraught part of swarm installation - 
for me anyway! Firstly because of the difficulty in 
identifying what libs (in what versions, formats, and
locations) are already installed; secondly in installing
extra and/or updated libs; and thirdly (worst of all)
making sure that the correct one (of multiple available
versions) is used in each case...

A good starting point (on Linux) is:

  $ ldd -p

which gives a listing of the installed *shared* libs
that ld.so will be able to find.  Of course this is not
(necessarily) the same as what gcc (more properly ld)
will link against, nor does it automatically tell us
where to find related .h files (of whether they are
even installed) but it does give an initial idea of
what may or may not be available...



libXpm:

  $ /sbin/ldconfig -p |grep libXpm
    78 - DLL libXpm.so.6 => /usr/i486-unknown-linuxaout/lib/libXpm.so.6.3.0
    79 - ELF libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4.3
    80 - ELF libXpm.so.4 => /usr/lib/libXpm.so.4.3
    81 - DLL libXpm.so.3 => /usr/i486-unknown-linuxaout/lib/libXpm.so.3.3.0
    82 - DLL libXpm.so.3 => /usr/i486-unknown-linuxaout/lib/libXpm.so.3.2g

so ... I have a variety of libXpm's available in both ELF and
DLL forms. I presume (?) DLL is the old - obsolescent - Linux
shared lib format; my apps will almost certainly not link
against them, though that will need checking later; the point
for now is that I do have ELF format libs at version 4.3; swarm 
developers are documented as using 3.4f, so we should be OK...



tcl/tk:

  $ /sbin/ldconfig -p |grep tcl   
    11 - ELF libtclx.so.7.4 => /usr/lib/libtclx.so.7.4
    12 - ELF libtclx.so.7.3 => /usr/lib/libtclx.so.7.3
    13 - ELF libtcl.so.7.4 => /usr/lib/libtcl.so.7.4
    14 - ELF libtcl.so.7.3 => /usr/lib/libtcl.so.7.3

  $ /sbin/ldconfig -p |grep tk 
     4 - ELF libtk.so.4.0 => /usr/lib/libtk.so.4.0
     5 - ELF libtk.so.3.6 => /usr/lib/libtk.so.3.6

I don't know what libtclx is, so I'll ignore it (;-)

The main point is that we seem to have tcl 7.3 and 7.4
and tk 3.6 and 4.0; swarm wants at least 7.4/4.0 (?)
so we should be OK - but may have to take care that we don't
accidentally use 7.3/3.6.  Note that it would *not* be
a good idea to simply remove the 7.3/3.6 libs; the
likelyhood is that they are present for a reason - i.e.
*some* Linux FT bundled apps may well require them...



BLT 2.1:

This was where the fun started ...

In my configuration I found (via ldconfig) that I had both static 
and shared BLT libs in /usr/lib; shared versions were present
at both 1.7 and 1.8 revisions; there was no obvious way
of determining the version of the .a (is there are standard
mechanism or convention on this?) - but chances were, it
was 1.8.  Now I *know* I need at least 2.1 for swarm,
so I'm going to have to install that - and make sure the
old one is not used in preference.

First point: ftp.neosoft.com *has* now been reorganised,
and BLT is not where it was.  I found it at:

 http://www.NeoSoft.com/tcl/ftparchive/sorted/devel/BLT2.1.tar.gz

(Of course: I could simply have taken the copy from the
swarm FTP site - would have been faster! But I wanted
to try and make sure I got the most recent version ...
but it actually turned out to be just 2.1 anyway, so
it didn't make any difference...)

OK, I unpacked the archive and ran ./configure. Worked
except for not recognising the configuration
"i686-unknown-linux", and not finding either tcl.h or
tk.h. The unrecognised configuration turned out to mean
that it would not build a *shared* version of the BLT
lib, but I ignored that for now.  First problem was to
find tcl.h and tk.h:

Linux-FT packages are located on the runtime CD 
(normally mounted on /dist) under usr/pkg; these are
automatically cached onto /usr/pkg as needed. So,
the logical place to look for these headers is 
somewhere in /dist/usr/pkg:

  # find /dist/usr/pkg -name tcl.h
  /dist/usr/pkg/gcc-i486-unknown-linuxaout/mirror/lib/gcc-lib/
    i486-unknown-linuxaout/2.7.2/sys-include/tcl.h
  /dist/usr/pkg/tcl7.4/lib/tcl7.4/include/tcl.h
  /dist/usr/pkg/tcl-7.3/mirror/lib/7.3/include/tcl.h
  /dist/usr/pkg/tcl-7.4/mirror/lib/7.4/include/tcl.h

Since I know I want tcl 7.4 I plump for:

  /usr/pkg/tcl7.4/lib/tcl7.4/include
  
tk.h is also there, so I manually insert these into
the config.BLT file and rerun ./configure.  I note that
libtcl.a and libtk.a are being automatically found by
configure at:

  /usr/lib/tcl7.4/lib

This turns out to have the shared versions also (*and*
the BLT 1.8 libs!); the files in /usr/lib (identified by
ldconfig) are actually sym links to here.

So now I can build BLT - which works fine except that,
as already noted, no shared lib was built.  At the time
I deferred looking into that; but eventually found the 
problem in the cf/config.sub script which recognised
Intel CPU names from i386 thru i586 but had not been
updated for i686 (i.e. Pentium Pro). So i just replaced
every string of the form "i[345]86" by "i[3456]86"
(NB: these are literal strings in the file).  Rerunning
configure now correctly recognised the machine type
and knew how to build a shared lib - so I built it
and did a make install to install everything.

There was still the lingering question of which BLT lib
would actually get used, but I deferred that...



libtclobjc:

This is not a standard lib, so I knew I had to grab it from
the swarm site and install it.

So I downloaded, unpacked it, and ran ./configure; it failed
with this info:

  ...
  checking for -lobjc... no
  checking for objc_next_class... no
  You must apply the patch ./gcc.patch to the gcc source dir
  then recompile and install libobjc.a,
  then rerun this configure script.

This was a bit strange; partly because it seemed to indicate
the libobjc was missing (it's supposed to be bundled with
gcc - and I *know* I have gcc?); and partly because there is
no such file as "./gcc.patch".  I will probably never know
the true story behind this message (though I suspect it's
obsolete and should not have been given).  The "real" problem
was that libobjc was, indeed, not being found by gcc - as I
found by trying to build a minimal objc test program ("hello
world" - no swarm stuff). Next question was where, if anywhere
libobjc might be.  Try looking in /usr/pkg again...

  # find /dist/usr/pkg -name "*libobjc*"
  /dist/usr/pkg/objc/mirror/lib/gcc-lib/i486-unknown-linux/2.7.2/libobjc.a
  /dist/usr/pkg/objc/mirror/lib/gcc-lib/i486-unknown-linux/2.7.0/libobjc.a

Clearly, the 2.7.2 one is the one I want - but why is it
not being found by gcc?  I need to check what dirs gcc is checking
which I can do by linking by example program with gcc -v. This shows
the default lib dirs as: 

  -L/usr/lib/gcc-lib/i486-unknown-linux/2.7.2 
  -L/usr/i486-unknown-linux/lib

So I add a sym link from:

  /usr/lib/gcc-lib/i486-unknown-linux/2.7.2/libobjc.a

to:

 /usr/pkg/objc/mirror/lib/gcc-lib/i486-unknown-linux/2.7.2/libobjc.a

I have no explanation for why this was not present originally -
it looks like a bug in the Linux-FT gcc installation.

Anyway, I can successfully compile and execute my test objc
program.  Try ./configure on libtclobjc again, and this time
it does much better, pausing only to complain that it can't
find tcl.h; as with BLT I give the dir as:

 /usr/pkg/tcl7.4/lib/tcl7.4/include

and the configure now completes successfully, as does the make
and the installation.  (I think some people have attempted to
make a shared lib version of this, but I did not attempt it.)



Configuring Swarm Libs:
=======================

Now, unpack the Swarm libs, and edit Makefile.conf:

 OTHERINCDIRS=-I/usr/pkg/tcl7.4/lib/tcl7.4/include 
    -I/usr/local/libtclobjc/include
 OTHERLIBDIRS=-L/usr/local/blt/lib -L/usr/local/libtclobjc/lib
 OTHERLIBS=-lieee

I throw in the -lieee here because I have had previous
experience with needing this on a Linux platform - it may not
be necessary.

The make completed successfully, and I was ready to attempt
building an app. Since I have an app of my own, I bypassed
the attempt to build the standard sample apps, and tried
my own instead.

But first: I need to rerun ldconfig so it can find out
about the new BLT .so.  I edit /etc/ld.so.conf to add
the (new) BLT lib dir to the list of lib dirs, then
rerun ldconfig.

OK, now rebuild my model (OK) and run ldd to check which
shared libs it has linked against:

  $ ldd scl
    libtk.so.4.0 => /usr/lib/libtk.so.4.0
    libtcl.so.7.4 => /usr/lib/libtcl.so.7.4
    libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4.3
    libX11.so.6 => /usr/X11R6/lib/libX11.so.6.1
    libm.so.5 => /lib/libm.so.5.0.5

Strangely, it has not linked against any shared version of
libBLT.  A good tool at this stage is to add the option
"-Wl,-M" to EXTRALDFLAGS in swarm's Makefile.conf to
generate a linker map file.  This revealed that libBLT.a
was being used in preference to the .so; a little
experiment reveals that I need a sym link from libBLT.so
to libBLT.so.2 (this is *not* automatically created by
ldconfig).  Once this is in place we get:

$ ldd scl
        libBLT.so.2 => /usr/local/blt/lib/libBLT.so.2.1
        libtk.so.4.0 => /usr/lib/libtk.so.4.0
        libtcl.so.7.4 => /usr/lib/libtcl.so.7.4
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4.3
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6.1
        libm.so.5 => /lib/libm.so.5.0.5

OK, try executing ... and - it crashes with:

  scl: can't resolve symbol '__isnan'

I then noticed that libc.so is *not* showing up in the
ldd list above; and stranger still, when I add an explicit
"-lc" to OTHERLIBS, we get:

  $ ldd scl
    libBLT.so.2 => /usr/local/blt/lib/libBLT.so.2.1
    libtk.so.4.0 => /usr/lib/libtk.so.4.0
    libtcl.so.7.4 => /usr/lib/libtcl.so.7.4
    libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4.3
    libX11.so.6 => /usr/X11R6/lib/libX11.so.6.1
    libm.so.5 => /lib/libm.so.5.0.5
    libc.so.5 => /lib/libc.so.5.2.18

So now we have libc.so included in the link; and the
program runs successfully.  This seems pretty weird to me!

In fact, these symptoms are impossible (;-) on two different
counts:

  o If libc is *not* being being, and __isnan is referenced,
    and is defined only in libc, then the linker should
    generate an unresolved symbol at link time...

  o But, in any case, unless explicitly told otherwise,
    gcc is supposed to always (?) include libc for searching
    by the linker..

I have looked into this only a *little* further using "gcc -v"
to see what options gcc is invoking ld with: I find that 
when gcc is invoked without "-g" (the debug switch) then
it does explicitly include "-lc" in the ld command; but when
the "-g" switch is present, there is no "-lc", but a "-lg"
instead.

I'm going to ignore this since I can apparently work around
it by including "-lc" explicitly; but I'd appreciate it if
any gcc gurus out there could explain what might be going on
here!

====================

That's it - hope it's of some help to somebody!

Barry.