eap@bu-pub.bu.edu (Eric A Pearce) (02/03/91)
We have both Sun and Ultrix machines (also SGI and IBM RS/6000) and most of my time is spent making the same software work on different platforms. Shared libraries: They can be very useful, but they complicate administration. For example - suppose I want to replace a function with a new version, I use the "shlib.custom" kit (SunOS >= 4.1) to make a new shared libc and every dynamically linked executable will use the new library. Under the current Ultrix, I would need to re-link every executable that calls libc. A typical application of this involves replacing NIS routines with resolver-only versions for hostname lookup. This doesn't seem to be an issue now, as Ultrix 4.0 seems to have gone the "kitchen sink" approach with every lookup method included and configurable in any order (/etc/hosts, NIS(YP) and DNS/BIND/Hesiod). SGI IRIX also does this. Most of the hazards of shared libraries can be avoided by testing your new library by using the environment variable LD_LIBRARY_PATH to control the search path. If you make your new library with a higher version number than the installed one, you can back out of a mistake by using "mv" to move your new library to a safe place and the system can go back to the previous version. I have no idea why Sun has "ldconfig" dynamically linked, this seems really silly, as you use this command to rebuild the shared library cache. I have come up against this kind of thinking (or lack of) before, as in the mini-root on the Sun386i, where "ls" is dynamically linked, so you have to poke around the filesystem using "echo *". This is only good when you are trading "war" stories at Usenix. Another disadvantage of shared libraries comes up when trying to distribute software to customers who may not have the same software packages as on your "build" machine. I recently built a large software package that used Sun C, Sun Fortran, MIT X11 R4 and SunView (all these use shared libraries). If I link this package in a dynamic manner (the default action), I now have to worry about the destination machine having all these packages installed and of the same version for my code to be of any use. Under Ultrix (and "static" Sun) I would take up more disk space, but my executable stands a fair chance of working under Ultrix 3.1, 4.0 or 4.1. I did run into trouble with 3.1 executables under 4.0, as it looks like the hostname lookup routines changed enough to break them. Disk space is real issue, I'm been trying to stuff usable Ultrix 4.0 and 4.1 systems on rz24s (~200meg). My Sun Sparc2 with the same drive is able to fit a pretty complete OS distribution on it. Large software packages on Ultrix (such as Motif) would really benefit from shared libraries - the resulting Ultrix executables are *huge*. -e -- ------------------------------------------------------------------------------- Eric Pearce eap@bu-pub.bu.edu Boston University Information Technology 111 Cummington Street, Boston MA 02215 617-353-2780 voice 617-353-6260 fax