As see on Linux when running:

  saoconfig shmainlib
  make
  make shmainlib
  setenv LD_LIBRARY_PATH .
  gcc -g -o tmain -I. -I./util tmain.c libfuntoolsMainLib.a libfuntools.a -ldl -lm
or
  gcc -g -o tmain -I. -I./util tmain.c libfuntools.a -ldl -lm
  ./tmain -s libfuntoolsMainLib.so $S "fundisp foo[cir(512,512,.1)]"

gives:
...
0xb7ef80f4 0xb7ef80f4
0xb7ef80f4
0xb7ef80f4 0xb7ef80f4
executing: fundisp "buf:0xb7f3e008:648000[cir(512,512,.1)]" 
0x8062650
0x8062650 0x8062650

The hex numbers are the address of the mainlibhead list header for
mainlib records. How can this address change?

We link tmain against either libutil.a or libfuntools.a to get the
MainLibLoad() routine. When this routine is called, it loads the
libfuntoolsMainLib.so library, and, using that library calls
funtoolsMainLibInit(). This routine makes a bunch of MainLibNew()
and uses mainlibhead in the static executable as the list head.

Apparently, because we add -L. -lfuntools to the mklib command line:

	./mklib -o $(PACKAGE)MainLib -L. -lfuntools $(PACKAGE)tmp/*.o; \

libfuntools.so is loaded as well. This has the mainlib.o module in it,
and of course, a new copy of mainlibhead.

So, when MainLibProcess() is subsequently called, it probably comes
from the shared object, not the statically linked executable. At any
rate, it uses the mainllibhead from the shared object, which is NULL,
and therefore does not see that fundisp has been defined.

If we don't add -L. -lfuntools to the mklib command line:

    ./mklib -o $(PACKAGE)MainLib $(PACKAGE)tmp/*.o; \

and remake the libfuntoolsMainLib.so file, we get an error when we try to run:

  make shmainlib
  mklib: Making Linux shared library:  libfuntoolsMainLib.so.1.0
  ./tmain -s libfuntoolsMainLib.so $S "fundisp foo[cir(512,512,.1)]"
  can't load shared object libfuntoolsMainLib.so (./libfuntoolsMainLib.so: undefined symbol: SAOdtype)

This is because the statically linked program does not call SAOdtype
and therefore does not have it linked in. It must come from a loaded
shared object.

So we have to load a shared object to get funtools entry points, but we
don't want a second copy of mainlibhead ...

Even if we separate MainLibLoad from mainlib.c and don't explicitly
load mainlib.c, we still get the wrong mainlibhead:

	nm tmain | egrep mainlib
	08062650 b mainlibhead
	08062654 b mainlibinit
	08062658 b mainlib_path
	080625f0 d mainlibundef