Jonathan Adams wrote: > On Wed, Aug 23, 2006 at 03:33:29PM -0400, Jim Connors wrote: >> Working to create a minimal embedded Solaris configuration. With a >> modest investment, it's not too hard to boot a version with a footprint >> of 50-60MB. One of the first tasks here is to select only the critical >> Solaris packages to install. There are many that have serious issues >> with Sys V packaging; I'm not one of them however, current Solaris >> packages are too large (not granular enough) to address the embedded market. >> >> The end result is that in a 50-60MB config, there's still lots that can >> be trimmed. One of the potential candidates is the plethora of shared >> objects. I was trying to figure out an automated way to determine which >> shared objects are not being used. One such idea was to create script >> to run ldd(1) on all executables and gather up the referenced so's, and >> remove those that weren't referenced. This didn't work. >> >> Would there by some automated way to determine which shared objects in a >> system may not be referenced? > > Look at the access times of the files?
Hmm. So are you suggesting that I run all the executables of interest and see which so's are accessed? If so, would this require exercising all of the command-line options in case additional so's are loaded? > >> Some libraries, notably those that have separate subdirectories under >> /usr/lib, do not have a version (e.g. .so.1) associated with the .so >> files. Are these different? > > Generally, they are plugins that are dlopen()ed by various libraries or > applications. So would it be reasonable to assume that so's that don't have the version suffix might be dlopen candidates? Maybe I'll just exclude them from the removal algorithm? Thanks, -- Jim C > > Cheers, > - jonathan >
