Greg Abram:
|I see what you mean - it looks like its not possible to have one shared lib
|dependent on another. Thats news to me, and sucks.
No, you can have them dependent on one another. And on most platforms the
dependency can be implicit, so the guy hacking Makefiles doesn't have to
know about the dependencies (that is, "-lLibA" when LibA.so depends on
libB.so automagically links with libB too).
The thing is you lose the concept of a separately-linkable module that you
have with a static lib. With a static lib, if you don't reference a symbol
in a .o, it doesn't get linked (AFAIK). With a shared library, if you use
symbols in the shared lib, generally all of its symbols have to resolve.
See elfdump -Dl libMagick.so (on IRIX at least) for one of many examples of
implicitly dependent shared libs. It'd actually be great if DX built
shared libs with implicit depedencies. Then folks that link in libDX or
libDXcallm wouldn't have to go chase down the umpteen libraries that were
referenced by it (Magick, hdf, netcdf, etcetc.) and hand-specify these
dependencies (which may change if DX is rebuilt!) in a Makefile.
Currently, you have to do this.
>From what's been said, sounds like the simplest solution to our problems
would be to make DXlite an implicit dependency of libDXL. For example
(IRIX):
ld -shared -o libDXL.so *.o -lDXlite ... -rpath $(INSTALL_LIB_DIR) -n32
Looking at the sizes of the libraries:
-rw-r--r-- 1 root sys 13215524 May 22 07:09 libDX.a
-rw-r--r-- 1 root sys 205412 May 22 07:09 libDXL.a
-rw-r--r-- 1 root sys 12353988 May 22 07:09 libDXcallm.a
-rw-r--r-- 1 root sys 1332372 May 22 07:08 libDXlite.a
that doesn't look too unreasonable.
Randy
