On Wed, Aug 23, 2006 at 05:56:29PM -0400, Jim Connors wrote: > 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?
That would be the problem. It's not trivial to discover all possible SOs. ldd(1) gives you all of the linked-against libraries. There are plenty pulled in via other means. > >>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? That's probably a good idea. This may not have full coverage, though; some plugins have the ".so.1" suffix anyway. (i.e. nss_*.so.1 for the name service switch) Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
