Garrett D'Amore <[EMAIL PROTECTED]> wrote complaining about the
sizes of some binaries, and about differences in libraries needed
between various architectures.
The first thing is, if you're only using VIOCNEWCELL &
other pioctl's, then you almost certainly only "really"
need afs/libsys.a. However, you are *probably* using
pioctl not lpioctl, so there's something you should know.
lpioctl does the actual kernel call. pioctl is a wrapper,
which on AFS machines calls lpioctl, and on NFS, uses
rx to talk to rmtsysd on the nfs/afs translator which
then issues an lpioctl on your behalf. Unless you need to
support NFS clients, you can likely get away with using
lpioctl and just afs/libsys.a If you link with lpioctl,
you can probably get away with just libsys.a.
You also complained about library ordering problems. I've always
found there's a certain amount of trial & error, but there's usually
some order that pleases every machine. Some reasons for why machines
can differ:
(1) Different machines omit different features.
AFS libraries that need these features
generally need to be linked with util.a
(2) Different linkers resolve symbols differently.
The RS/6000 linker is the most interesting
culprit, because it doesn't care what
order libraries are ordered in.
(3) AFS libraries generally use the "bsd" rather
than the "native" include files and libraries.
That doesn't influence load order, but it
does make life generally much more difficult.
The order of dependencies of libraries is a rooted tree, so there
are many orderings that will work. Here is one that I believe will
always work:
library approximate list of
direct dependencies [4]
afs/libxstat_fs.a rx,lwp,util
afs/libxstat_cm.a rx,lwp,util
afs/libfsprobe.a volser,rx,lwp,util
afs/libbos.a rx,com_err
afs/libvolser.a vldb,auth,rxkad,ubik,rx,cmd,com_err,util
afs/libvldb.a rx,com_err
afs/vlib.a [2] sys,lwp,util
afs/libdir.a
afs/libacl.a ubik
afs/libkauth.a [1] auth,rxkad,ubik,rx,com_err,des
afs/libprot.a auth,rxkad,ubik,rx,com_err
afs/libauth.a [1] [3] audit,rxkad,sys,lwp,com_err,des
afs/libaudit.a rxkad
librxkad.a com_err,des
libubik.a rx,lwp,com_err
afs/libsys.a rx,util
afs/libafsint.a rx
librx.a lwp
liblwp.a
afs/libcmd.a com_err
afs/libcom_err.a
libdes.a
afs/util.a [2]
Note that there are 23 libraries in question. Most
real applications only need a small subset of these libraries.
For most typical applications, this will suffice:
kauth prot auth rxkad ubik sys rx lwp cmd com_err des util
[1] These libraries also have a .krb.a form. You should
probably use those if you use login.krb & klog.krb. The
difference may not matter for most purposes.
[2] These libraries don't start with lib, so the loader -l
option doesn't work with these.
[3] For client side libraries, you can omit -laudit if you either
(a) obtain a fixed copy of libauth.a that has afsconf_CheckAuth in
userok.o instead of authcon.o, or (b) include this dummy scrap
of code somewhere in your application, preferably in the file
that contains main(): "osi_audit(){}".
[4] Libraries may also have indirect dependencies, for instance,
afs/libaudit.a needs libdes.a, because librxkad.a does. Dependencies
also depend on which .o's you reference in a library; if you don't
reference the .o that references another library, you may not need
to supply that library. Hence, if you only use lpioctl (from libsys.a),
then you don't need librx.a, because you aren't referencing
libsys.a(rmtsysc.o) which needs rx.
This is *only* an approximate list. Libraries can and do differ
slightly between AFS releases, and may have other dependencies.
Shared libaries are most useful if you nearly always have
at least one program loaded which is referencing the library,
and you have many different programs which use that same library.
The classical example is X, where it would be unusual not to have
several different programs loaded & using the same library.
Shared libraries are also an obvious win with libc.a. With
the various AFS libraries, shared libraries aren't nearly so
obvious a win. On most machines, AFS commands are invoked
rarely, and few commands persist in memory for more than a
few seconds. It is probably that shared libraries would
have at least some performance penalty, and few advantages.
Where one might realize an advantage with shared libraries
is if you were interested in saving space. For instance,
if you were trying to distribute all of pts, fs, & other
tools via floppy, and wanted to minimize the # of floppies.
Shared libraries might also be a minor advantage on a memory
starved machine that was running scripts that invoked many
different AFS commands in rapid succession. Shared libraries
might also be an advantage on an AFS server, where one would
indeed expect to find several long-running processes all
at once (but purchasing more memory is almost certainly still
a better win.)
Of course, the administrative difficulties of shared libraries
are many. Keeping track of different versions of the libraries
and utilities would be a pain, at best - many sites put these
binaries in all sorts of non-standard locations, and dealing
with bugs introduced by version skew (which Transarc seems
particularly talented at introducing) would certainly be a pain.
With 23 libraries, it would also be difficult to figure out
how to slice things to make shared libraries. One would
almost certainly *not* want to just take the libraries as is;
most contain both code that one would expect to use in standard
client applications, and code that would only be used by
server applications and doesn't need to be in the client side
at all.
All in all, I'm not surprised that transarc doesn't distribute
shared libraries by default.
-Marcus Watts
UM ITD PD&D Umich Systems Group
