I assume you want to remove anything unneeded. So start with the largest files (library, binary, whatever) and work your way downwards to smaller files.
You could look at the package dependency map, as a way to understand which binaries go with which libraries. You might try sorting all packages by size, then looking at the largest package first, and see if you can leave out that entire package (and the things that depend on it). You could try using "pkgrm" on an official Solaris install since that would warn you about dependencies. Again, start with the largest package the might be unused. It also might help to identify major sections of OS functionality that you won't be using NFS server, print server, etc, etc. You could try looking at svcs command for a list of the various runtime services that are available, then hunt down the files on disk that support the ones you don't need. Please understand that your partial Solaris image will be untested. Any guarantee against crashing and/or subtle bugs, would have to come from your own testing. --chris 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? > > 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? > > Thanks, > -- Jim C > > > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org
