1 2CDDL HEADER START 3 4The contents of this file are subject to the terms of the 5Common Development and Distribution License, Version 1.0 only 6(the "License"). You may not use this file except in compliance 7with the License. 8 9You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE 10or http://www.opensolaris.org/os/licensing. 11See the License for the specific language governing permissions 12and limitations under the License. 13 14When distributing Covered Code, include this CDDL HEADER in each 15file and include the License file at usr/src/OPENSOLARIS.LICENSE. 16If applicable, add the following below this CDDL HEADER, with the 17fields enclosed by brackets "[]" replaced with your own identifying 18information: Portions Copyright [yyyy] [name of copyright owner] 19 20CDDL HEADER END 21 22Copyright 2000 Sun Microsystems, Inc. All rights reserved. 23Use is subject to license terms. 24 25ident "%Z%%M% %I% %E% SMI" 26 27What does this tool do for you? 28 29This tool statically analyzes executable files and tries to figure out 30dependencies on libraries and other executable files. It is important to 31recognize that the output of this tool may not be the definitive dependency 32list, but the output should give you pointers on possible dependencies. 33 34For more information on how this tool works, see "How does this tool work?" 35below. 36 37 38 39This set of tools contains 7 files: 40 41 1. DependencyCheck.txt - the file you are currently reading 42 2. make_pkg_db - generate database to reflect the software installed 43 3. SampleLinks - sample link resolution file for 44 /var/sadm/install/contents(see notes on make_pkg_db) 45 4. SamplePkgLinks - sample link resolution file for 46 a package pool (see notes on make_pkg_db) 47 5. get_depend_info - analyze executables, requires database files 48 6. make_pkg_db.txt - text formatted man page 49 7. get_depend_info.txt - text formatted man page 50 51 52 53 54How to use this tool: 55 56 a. run make_pkg_db with the -dbdir argument 57 b. read the README notes on make_pkg_db and decide if you 58 want to resolve the symbolic links 59 c. run the get_depend_info tool and specify the directory with 60 the package database files 61 62 63 64How does this tool work? 65 66At a high level, this tool uses /usr/bin/ldd and /usr/bin/strings to figure 67out what an executable file depends upon. Since this is a static analysis 68there is no way to know if the dependencies identified will actually be 69executed. 70 71The strings command will not be run on binaries if the user specifies the 72-cons option for get_depend_info. 73 74This tool cannot resolve variable substitions. For example if a shell script 75set "$MYPATH" to "/usr/sbin" and then executes "$MYPATH/df", this tool will 76not be able to resolve that the shell script will execute "/usr/sbin/df". 77 78The only way to conclusively know all the dependencies is to do a runtime 79analysis. Furthermore, to get the complete set of dependencies, you would need 80to run all permutations of the executable being analyzed. Clearly a definitive 81dependency check would be a tremendous amount of work and outside the scope 82of this tool. 83 84This tool divides executables into three broad groups - kernel modules, 85binaries and shell scripts. 86 87For all three types of files, all the output is verified against the entries 88in database generated by make_pkg_db. This technique allows the tool to verify 89that a dependency was part of the Solaris installation and determine which 90package a given dependency came from. 91 92 93 94A. Dependency Checks on Kernel Modules 95 96Kernel modules are identified by having a "/kernel/" somewhere in their 97path. If an input is identified as a kernel module, then an ldd is run on 98that module. If the ldd returns output, then the tool parses that output 99to see if it can find the library in /kernel or in /usr/kernel. For example, 100if the tool runs on /kernel/drv/mydrv, the ldd will return something like 101"misc/mylib". The tool will look for "mylib"in /kernel/misc/mylib or 102/usr/kernel/misc/mylib. 103 104If the ldd returns nothing, then a "strings" command is run on the kernel 105module. Again, the output of the strings is compared against /kernel and 106/usr/kernel to see if there is a match. This method was designed to catch 107the "_depends_on" string embedded in some kernel modules. 108 109Note, if the ldd succeeds, then a strings will not run on the kernel module. 110 111 112B. Binary files 113 114Binary files have both the ldd and strings command run on them. The output of 115both programs is parsed and checked against the contents of the database 116generated by make_pkg_db. 117 118If the user specifies the -cons option on get_depend_info, then the strings 119analysis will not be done. This is a more conservative approach which only 120uses ldd and therefore has realiable output. 121 122 123C. Shell scripts 124 125Shell scripts are parsed to remove comments and break the script into tokens 126of the file. All the tokens in the file are cross-checked against the database 127generated by make_pkg_db to determine if a dependency exists. 128 129 130