CDDL HEADER START

The contents of this file are subject to the terms of the
Common Development and Distribution License, Version 1.0 only
(the "License").  You may not use this file except in compliance
with the License.

You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
or http://www.opensolaris.org/os/licensing.
See the License for the specific language governing permissions
and limitations under the License.

When distributing Covered Code, include this CDDL HEADER in each
file and include the License file at usr/src/OPENSOLARIS.LICENSE.
If applicable, add the following below this CDDL HEADER, with the
fields enclosed by brackets "[]" replaced with your own identifying
information: Portions Copyright [yyyy] [name of copyright owner]

CDDL HEADER END

Copyright 2000 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.

ident	"%Z%%M%	%I%	%E% SMI"

What does this tool do for you?

This tool statically analyzes executable files and tries to figure out
dependencies on libraries and other executable files.  It is important to
recognize that the output of this tool may not be the definitive dependency
list, but the output should give you pointers on possible dependencies.

For more information on how this tool works, see "How does this tool work?"
below.



This set of tools contains 7 files:

	1. DependencyCheck.txt - the file you are currently reading
	2. make_pkg_db - generate database to reflect the software installed
	3. SampleLinks - sample link resolution file for
		/var/sadm/install/contents(see notes on make_pkg_db)
	4. SamplePkgLinks - sample link resolution file for
		a package pool (see notes on make_pkg_db)
	5. get_depend_info - analyze executables, requires database files
	6. make_pkg_db.txt - text formatted man page
	7. get_depend_info.txt - text formatted man page




How to use this tool:

	a. run make_pkg_db with the -dbdir argument
	b. read the README notes on make_pkg_db and decide if you
	   want to resolve the symbolic links
	c. run the get_depend_info tool and specify the directory with
	   the package database files



How does this tool work?

At a high level, this tool uses /usr/bin/ldd and /usr/bin/strings to figure
out what an executable file depends upon.  Since this is a static analysis
there is no way to know if the dependencies identified will actually be
executed.

The strings command will not be run on binaries if the user specifies the
-cons option for get_depend_info.

This tool cannot resolve variable substitions.  For example if a shell script
set "$MYPATH" to "/usr/sbin" and then executes "$MYPATH/df", this tool will
not be able to resolve that the shell script will execute "/usr/sbin/df".

The only way to conclusively know all the dependencies is to do a runtime
analysis. Furthermore, to get the complete set of dependencies, you would need
to run all permutations of the executable being analyzed.  Clearly a definitive
dependency check would be a tremendous amount of work and outside the scope
of this tool.

This tool divides executables into three broad groups - kernel modules,
binaries and shell scripts.

For all three types of files, all the output is verified against the entries
in database generated by make_pkg_db.  This technique allows the tool to verify
that a dependency was part of the Solaris installation and determine which
package a given dependency came from.



A.  Dependency Checks on Kernel Modules

Kernel modules are identified by having a "/kernel/" somewhere in their
path.  If an input is identified as a kernel module, then an ldd is run on
that module.  If the ldd returns output, then the tool parses that output
to see if it can find the library in /kernel or in /usr/kernel.  For example,
if the tool runs on /kernel/drv/mydrv, the ldd will return something like
"misc/mylib".  The tool will look for "mylib"in /kernel/misc/mylib or
/usr/kernel/misc/mylib.

If the ldd returns nothing, then a "strings" command is run on the kernel
module.  Again, the output of the strings is compared against /kernel and
/usr/kernel to see if there is a match.  This method was designed to catch
the "_depends_on" string embedded in some kernel modules.

Note, if the ldd succeeds, then a strings will not run on the kernel module.


B. Binary files

Binary files have both the ldd and strings command run on them.  The output of
both programs is parsed and checked against the contents of the database
generated by make_pkg_db.

If the user specifies the -cons option on get_depend_info, then the strings
analysis will not be done.  This is a more conservative approach which only
uses ldd and therefore has realiable output.


C. Shell scripts

Shell scripts are parsed to remove comments and break the script into tokens
of the file.  All the tokens in the file are cross-checked against the database
generated by make_pkg_db to determine if a dependency exists.