Print this page
9139 check_rtime should be able to forbid libraries
9140 check_rtime should learn libnsl is safe now
9141 check_rtime exceptions could be cleaner

@@ -1,217 +1,210 @@
 CHECK_RTIME(1ONBLD)           illumos Build Tools          CHECK_RTIME(1ONBLD)
 
-
-
 NAME
        check_rtime - check ELF runtime attributes
 
 SYNOPSIS
-       check_rtime [-imosv] [-D depfile | -d depdir] [-E errfile] [-e exfile]
-       [-f listfile] [-I infofile] [-w outdir] file | dir, ...
+     check_rtime [-imosv] [-D depfile | -d -depdir] [-E errfile] [-e exfile]
+                 [-f listfile] [-I infofile] [-w outdir] file | dir ...
 
 DESCRIPTION
        check_rtime attempts to check a number of ELF runtime attributes for
-       consistency with common build rules.  These checks involve running
-       ldd(1) and elfdump(1) against a family of dynamic objects.  A dynamic
-       object can be defined explicitly as a file or multiple dynamic objects
-       can be located under the directory dir.
+     consistency with common build rules.  These checks involve running ldd(1)
+     and elfdump(1) against a family of dynamic objects.  A dynamic object can
+     be defined explicitly as a file or multiple dynamic objects can be
+     located under the directory dir.
 
        check_rtime is typically called from nightly(1ONBLD) when the -r option
        is in effect. In this case the dynamic objects under the associated
        proto area ($ROOT) are checked.  check_rtime can also be run standalone
        against any set of dynamic objects.
 
        check_rtime uses ldd(1) to verify dependencies. This implies that by
        default any object inspected will bind to its dependencies as they are
        found in the underlying system.  Use of the -D, -d option, or the
-       existence of the environment variables $CODEMGR_WS/$ROOT instruct
-       check_rtime to establish an alternative dependency mapping using
-       runtime configuration files generated with crle(1).
+     existence of the environment variables $CODEMGR_WS or $ROOT instruct
+     check_rtime to establish an alternative dependency mapping using runtime
+     configuration files generated with crle(1).
 
        check_rtime uses ldd(1) to completely relocate any dynamic object and
-       thus detect missing dependencies, unsatisfied symbol relocations,
-       unused and unreferenced dependencies. These checks are carried out for
-       the following reasons:
+     thus detect missing dependencies, unsatisfied symbol relocations, unused
+     and unreferenced dependencies.  These checks are carried out for the
+     following reasons:
 
        o   An object that cannot find its dependencies may fail to load at
            runtime.  This error condition often goes unnoticed because the
            existing use of the object is as a dependency itself, and the
-           objects' dependencies are already satisfied by the caller.
-           However, if the object itself is unable to satisfy its
-           dependencies, its use in new environments may be compromised.
+         objects' dependencies are already satisfied by the caller.  However,
+         if the object itself is unable to satisfy its dependencies, its use
+         in new environments may be compromised.
 
            A missing or erroneous runpath is the typical reason why an object
            can not locate its dependencies.  Use of the link-editors -zdefs
            option when building a shared object ensures required dependencies
            are established.  This flag is inherited from $(DYNFLAGS) in
            lib/Makefile.lib. Missing dependencies are displayed as:
 
              foo: bar.so.1 => (file not found)  <no -zdefs?>
 
-       o   Unsatisfied symbol relocations indicate that some thread of
-           execution through the object will fail when it is unable to locate
-           a referenced symbol.
+     o   Unsatisfied symbol relocations indicate that some thread of execution
+         through the object will fail when it is unable to locate a referenced
+         symbol.
 
            A missing, or mismatched version of a dependency is the typical
            reason for unsatisfied symbol relocations (see missing dependency
            discussion above). Unsatisfied symbol relocations are displayed as:
 
              foo: symbol not found: bar  <no -zdefs?>
 
            Note: Shared objects can make reference to symbol definitions that
            are expected to be defined by the caller. To indicate that such
-           symbols are not undefined in the usual sense, you must specify
-           these symbols in a mapfile, using the EXTERN or PARENT symbol
-           attribute. Without these symbol attributes, ldd(1) is unable to
-           determine the symbols special nature, and check_rtime will report
-           these symbols as undefined.
+         symbols are not undefined in the usual sense, you must specify these
+         symbols in a mapfile, using the EXTERN or PARENT symbol attributes.
+         Without these symbol attributes, ldd(1) is unable to determine the
+         symbols special nature, and check_rtime will report these symbols as
+         undefined.
 
        o   Unused dependencies are wasteful at runtime, as they take time to
-           load and relocate, but will not be used by the calling object.
-           They also result in unnecessary processing at link-edit time.
+         load and relocate, but will not be used by the calling object.  They
+         also result in unnecessary processing at link-edit time.
 
            Dependency lists (typically defined via $(LDLIBS)) that have been
-           yanked-and-put between Makefiles without verifying their need, are
-           a typical reason why unused dependencies exist.  Unused
-           dependencies are displayed as:
+         copy and pasted between Makefiles without verifying their need, are a
+         typicalreason why unused dependencies exist.  Unused dependencies are
+         displayed as:
 
              foo: unused object=bar.so.1  <remove lib or -zignore?>
 
-       o   Unreferenced dependencies are also wasteful at runtime, although
-           not to the extent of unused dependencies.  They also result in
+     o   Unreferenced dependencies are also wasteful at runtime, although not
+         to the extent of unused dependencies.  They also result in
            unnecessary processing at link-edit time.
 
-           Unreferenced dependency removal guards against a dependency
-           becoming unused when combined with different objects, or as the
-           other object dependencies evolve.  Unreferenced dependencies are
-           displayed as:
+         Unreferenced dependency removal guards against a dependency becoming
+         unused when combined with different objects, or as the other object
+         dependencies evolve.  Unreferenced dependencies are displayed as:
 
              foo: unreferenced object=bar.so.1;  \
                  unused dependency of libfoo.so.1  \
                  <remove lib or -zignore?>
 
            See also the section ENVIRONMENT VARIABLES.
 
-       o   Unused search paths are wasteful at runtime.  Unused search paths
-           are displayed as:
+     o   Unused search paths are wasteful at runtime.  Unused search paths are
+         displayed as:
 
              foo: unused search path=/usr/foo/lib  \
                  (RUNPATH/RPATH from file libfoo.so.1)  \
                  <remove search path?>
 
-       check_rtime uses elfdump(1) to look for a concatenated relocation
-       section in shared objects, the existence of text relocations, whether
-       debugging or symbol table information exists, whether applications have
-       a non-executable stack defined, duplicate entries in the symbol sorting
-       sections, and for direct bindings.  These checks are carried out for
-       the following reasons:
+     check_rtime uses elfdump(1) to look for a concatenated relocation section
+     in shared objects, the existence of text relocations, whether debugging
+     or symbol table information exists, whether applications have a non-
+     executable stack defined, duplicate entries in the symbol sorting
+     sections, and for direct bindings.  These checks are carried out for the
+     following reasons:
 
        o   A concatenated relocation section (.SUNW_reloc) provides optimal
            symbol table access at runtime, and thus reduces the overhead of
            relocating the shared object.  In past releases, the link-edit of a
-           dynamic object with the -z combreloc option was required to
-           generate a combined relocation section.  However, with the
-           integration of 6642769, this section combination is a default
-           behavior of the link-editor.
+         dynamic object with the -z combreloc option was required to generate
+         a combined relocation section.  However, with the integration of
+         6642769, this section combination is a default behavior of the link-
+         editor.
 
            In past releases, not inheriting $(DYNFLAGS) from lib/Makefile.lib
            was the typical reason for not having a concatenated relocation
            section. The misguided use of the -z nocombreloc option will also
-           prevent the creation of a concatenated relocation section. A
-           missing concatenated relocation section is displayed as:
+         prevent the creation of a concatenated relocation section.  A missing
+         concatenated relocation section is displayed as:
 
              foo: .SUNW_reloc section missing  <no -zcombreloc?>
 
        o   Text relocations result in impure text segments.  As text segments
            are typically read-only, they can be shared between numerous
            processes.  If they must be updated as part of the relocation then
-           the updated pages become unsharable and swap space must be
-           allocated to back these pages.  These events consume unnecessary
-           system resources and reduce overall system performance.
-
-           Not inheriting the $(PICS) rules from lib/Makefile.lib is the
-           typical reason for having non-pic code in shared objects.  Text
-           relocations are displayed as:
+         the updated pages become unsharable and swap space must be allocated
+         to back these pages.  These events consume unnecessary system
+         resources and reduce overall system performance.
+
+         Not inheriting the $(PICS) rules from lib/Makefile.lib is the typical
+         reason for having non-pic code in shared objects.  Text relocations
+         are displayed as:
 
              foo: TEXTREL .dynamic tag  <no -Kpic?>
 
        o   Debugging information is unnecessary in released objects.  Although
-           extensive when compiled -g, small quantities of debugging
-           information are stored in .stabs sections under normal
-           compilations.  This debugging information is geared towards aiding
-           debuggers locate relocatable objects associated with the dynamic
-           objects being debugged.  As relocatable objects aren't made
-           available as part of a software release this information has no
-           use.
+         extensive when compiled -g, small quantities of debugging information
+         are stored in .stabs sections under normal compilations.  This
+         debugging information is geared towards aiding debuggers locate
+         relocatable objects associated with the dynamic objects being
+         debugged.  As relocatable objects aren't made available as part of a
+         software release this information has no use.
 
            Not inheriting the correct $(LDFLAGS) from cmd/Makefile.cmd (which
-           asserts -s), or $(POST_PROCESS_SO) (which asserts strip -x) are
+         asserts -s) or $(POST_PROCESS_SO) (which asserts strip -x) are
            typical reasons for not removing debugging information.  Note,
-           removal of debugging information is only enabled for release
-           builds. The existence of debugging information is displayed as:
+         removal of debugging information is only enabled for release builds.
+         The existence of debugging information is displayed as:
 
              foo: debugging sections should be deleted  \
                  <no strip -x?>
 
-       o   All objects should retain their full .symtab symbol table.
-           Although this consumes disk space, it provides for more extensive
-           stack tracing when debugging user applications.
+     o   All objects should retain their full .symtab symbol table.  Although
+         this consumes disk space, it provides for more extensive stack
+         tracing when debugging user applications.
 
            Hard coding a -s flag with $(LDFLAGS) or $(DYNFLAGS) is the typical
-           reason for symbol tables being removed.  Objects that do not
-           contain a symbol table are displayed as:
+         reason for symbol tables being removed.  Objects that do not contain
+         a symbol table are displayed as:
 
              foo.so.1: symbol table should not be stripped  \
                  <remove -s?>
 
-       o   Applications should have a non-executable stack defined to make
-           them less vulnerable to buffer overflow attacks.
+     o   Applications should have a non-executable stack defined to make them
+         less vulnerable to buffer overflow attacks.
 
            Not inheriting the $(LDFLAGS) macro in cmd/Makefile.cmd is the
            typical reason for not having a non-executable stack definition.
            Applications without this definition are displayed as:
 
              foo: application requires non-executable stack \
                   <no -Mmapfile_noexstk?>
 
-
-       o   x86 applications should have a non-executable data segment defined
-           to make them less vulnerable to buffer overflow attacks.
+     o   x86 applications should have a non-executable data segment defined to
+         make them less vulnerable to buffer overflow attacks.
 
            Not inheriting the $(LDFLAGS) macro in cmd/Makefile.cmd is the
            typical reason for not having a non-executable data definition.
            Applications without this definition are displayed as:
 
              foo: application requires non-executable data \
                   <no -Mmapfile_noexdata?>
 
-
-       o   Solaris ELF files contain symbol sort sections used by DTrace to
-           map addresses in memory to the related function or variable
-           symbols. There are two such sections, .SUNW_dynsymsort for regular
-           symbols, and .SUNW_dyntlssort for thread-local symbols. To ensure
-           that the best names are shown for each such address, and that the
-           same name is given across Solaris releases, check_rtime enforces
-           the rule that only one symbol can appear in the sort sections for
-           any given address.  There are two common ways in which multiple
-           symbols or a given address occur in the ON distribution. The first
-           is from code written in assembly language. The second is as a
-           result of using #pragma weak in C to create weak symbols. The best
-           solution to this situation is to modify the code to avoid symbol
-           aliasing. Alternatively, the NODYNSORT mapfile attribute can be
-           used to eliminate the unwanted symbol.
+     o   Solaris ELF files contain symbol sort sections used by DTrace to map
+         addresses in memory to the related function or variable symbols.
+         There are two such sections, .SUNW_dynsymsort for regular symbols,
+         and .SUNW_dyntlssort for thread-local symbols.  To ensure that the
+         best names are shown for each such address, and that the same name is
+         given across Solaris releases, check_rtime enforces the rule that
+         only one symbol can appear in the sort sections for any given
+         address.  There are two common ways in which multiple symbols or a
+         given address occur in the ON distribution.  The first is from code
+         written in assembly language.  The second is as a result of using
+         #pragma weak in C to create weak symbols.  The best solution to this
+         situation is to modify the code to avoid symbol aliasing.
+         Alternatively, the NODYNSORT mapfile attribute can be used to
+         eliminate the unwanted symbol.
 
            Duplicate entries in a symbol sort section are displayed in one of
            the following ways, depending on whether the section is for regular
            or thread-local symbols:
 
              foo: .SUNW_dynsymsort: duplicate ADDRESS: sym1, sym2
              foo: .SUNW_dyntlssort: duplicate OFFSET: sym1, sym2
 
-
-       o   OSNet dynamic ELF objects are expected to employ direct bindings
+     o   illumos dynamic ELF objects are expected to employ direct bindings
            whenever feasible.  This runtime binding technique helps to avoid
            accidental interposition problems, and provides a more optimal
            runtime symbol search model.
 
            Not inheriting the correct $(LDFLAGS) from cmd/Makefile.cmd, or the

@@ -220,223 +213,197 @@
            contain direct binding information are displayed as:
 
              foo: object has no direct bindings \
                   <no -B direct or -z direct?>
 
-
-
        check_rtime also uses elfdump(1) to display useful dynamic entry
-       information under the -i option.  This doesn't necessarily indicate an
+     information under the --i option.  This doesn't necessarily indicate an
        error condition, but provides information that is often useful for
        gatekeepers to track changes in a release.  Presently the information
        listed is:
 
        o      Runpaths are printed for any dynamic object.  This is a historic
-              sanity check to insure compiler supplied runpaths (typically
-              from CC) are not recorded in any objects.  Runpaths are
-              displayed as:
+         sanity check to insure compiler supplied runpaths (typically from CC)
+         are not recorded in any objects.  Runpaths are displayed as:
 
              foo: RPATH=/usr/bar/lib
 
        o      Needed dependencies are printed for any dynamic object.  In the
-              freeware world this often helps the introducer of a new shared
-              object discover that an existing binary has become its consumer,
-              and thus that binaries package dependencies may require
-              updating.  Dependencies are printed as:
+         freeware world this often helps the introducer of a new shared object
+         discover that an existing binary has become its consumer, and thus
+         that binaries package dependencies may require updating.
+         Dependencies are printed as:
 
              foo: NEEDED=bar.so.1
 
-
-       check_rtime uses mcs(1) to inspect an object's .comment section.
-       During development, this section contains numerous file identifiers
-       marked with the tag "@(#)".  For release builds these sections are
-       deleted and rewritten under control of the $(POST_PROCESS) macro to
-       produce a common release identifier.  This identifier typically
-       consists of three lines including a single comment starting with the
-       string "@(#) SunOS".  If this common identifier isn't found the
-       following diagnostic is generated:
+     o   Dependencies may be marked as forbidden (see EXCEPTION FILE FORMAT)
+         this allows the build to warn should people use them accidentally.
+         Forbidden dependencies are printed as:
+
+               foo: NEEDED=bar.so.1     <forbidden dependency, missing
+               -nodefaultlibs?>
+
+     check_rtime uses mcs(1) to inspect an object's .comment section.  During
+     development, this section contains numerous file identifiers marked with
+     the tag "@(#)".  For release builds these sections are deleted and
+     rewritten under control of the $(POST_PROCESS) macro to produce a common
+     release identifier.  This identifier typically consists of three lines
+     including a single comment starting with the string "@(#) SunOS".  If
+     this common identifier isn't found the following diagnostic is generated:
 
              foo: non-conforming mcs(1) comment  <no $(POST_PROCESS)?>
 
-
        check_rtime uses pvs(1) to display version definitions under the -v
        option.  Each symbol defined by the object is shown along with the
        version it belongs to.  Changes to the symbols defined by an object, or
        the versions they belong to, do not necessarily indicate an error
-       condition, but provides information that is often useful for
-       gatekeepers to track changes in a release.
-
+     condition, but provides information that is often useful for gatekeepers
+     to track changes in a release.
 
 OPTIONS
        The following options are supported:
 
        -D depfile
-           Use depfile to generate an alternative dependency mapping.  depfile
-           must be created by 'find_elf -r'.  The -D and -d options are
-           mutually exclusive.
+             Use depfile to generate an alternative dependency mapping.
+             depfile must be created by find_elf -r.  The -D and -d options
+             are mutually exclusive.
 
-       -d depdir
+     -d depfile
            Use depdir to generate an alternative dependency mapping.
            find_elf(1ONBLD) is used to locate the ELF sharable objects for
-           which alternative mappings are required. The -D and -d options are
-           mutually exclusive.
+             which alternative mappings are required.  The -D and -d options
+             are mutually exclusive.
 
        -E errfile
            Direct error messages for the analyzed objects to errfile instead
            of stdout.
 
        -e exfile
-           An exception file is used to exclude objects from the usual rules.
-           See EXCEPTION FILE FORMAT.
+             An exception file is used to exclude objects from the usual
+             rules.  See EXCEPTION FILE FORMAT.
 
        -f listfile
            Normally, interface_check runs find_elf to locate the ELF objects
            to analyze. The -f option can be used to instead provide a file
            containing the list of objects to analyze, in the format produced
-           by 'find_elf -r'.
+             by find_elf -r.
 
        -I infofile
-           Direct informational messages (-i, and -v options) for the analyzed
-           objects to infofile instead of stdout.
+             Direct informational messages ( -i, and -v options) for the
+             analyzed objects to infofile instead of stdout.
 
-       -i  Provide dynamic entry information.  Presently only dependencies and
-           runpaths are printed.
+     -i      Provide dynamic entry information.  Presently only dependencies
+             and runpaths are printed.
 
        -m  Enable mcs(1) checking.
 
        -o  Produce a one-line output for each condition discovered, prefixed
-           by the objects name.  This output style is more terse, but is more
-           appropriate for sorting and diffing with previous build results.
+             by the objects name.  This output style is more terse, but is
+             more appropriate for sorting and diffing with previous build
+             results.
 
        -s  Determine whether .stabs sections exist.
 
-       -v  Provide version definition information. Each symbol defined by the
-           object is printed along with the version it is assigned to.
+     -v      Provide version definition information.  Each symbol defined by
+             the object is printed along with the version it is assigned to.
 
        -w outdir
            Interpret the paths of all input and output files relative to
            outdir.
 
 EXCEPTION FILE FORMAT
        Exceptions to the rules enforced by check_rtime are specified using an
-       exception file. The -e option is used to specify an explicit exception
+     exception file.  The --e option is used to specify an explicit exception
        file. Otherwise, if used in an activated workspace, the default
        exception file is $CODEMGR_WS/exception_list/check_rtime if that file
        exists. If not used in an activated workspace, or if
        $CODEMGR_WS/exception_list/check_rtime does not exist, check_rtime will
        use /opt/onbld/etc/exception_list/check_rtime as a fallback default
        exception file.
 
        To run check_rtime without applying exceptions, specify -e with a value
        of /dev/null.
 
-       A '#' character at the beginning of a line, or at any point in a line
+     A `#' character at the beginning of a line, or at any point in a line
        when preceded by whitespace, introduces a comment. Empty lines, and
        lines containing only comments, are ignored by check_rtime.  Exceptions
-       are specified as space separated keyword, and perl(1) regular
-       expression:
+     are specified as space separated keyword, and perl(1) regular expression:
 
            keyword  perl-regex
 
        Since whitespace is used as a separator, the regular expression cannot
-       itself contain whitespace. Use of the \s character class to represent
-       whitespace within the regular expression is recommended.  Before the
-       perl regular expression is used, constructs of the form MACH(dir) are
-       expanded into a regular expression that matches the directory given, as
-       well as any 64-bit architecture subdirectory that might be present
-       (i.e. amd64, sparcv9). For instance, MACH(lib) will match any of the
-       following:
+     itself contain whitespace.  Use of the `' character class to represent
+     whitespace within the regular expression is recommended.
+
+     Before the perl regular expression is used, constructs of the form
+     MACH(dir) are expanded into a regular expression that matches the
+     directory given, as well as any 64-bit architecture subdirectory that
+     might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
+     match any of the following:
 
            lib
+
            lib/amd64
+
            lib/sparcv9
 
        The exceptions understood by check_rtime are:
 
        EXEC_DATA
-
-                        Executables that are not required to have non-
-                        executable writable data segments
-
+             Executables that are not required to have non-executable writable
+             data segments
 
        EXEC_STACK
-
-                        Executables that are not required to have a non-
-                        executable stack
-
+             Executables that are not required to have a non-executable stack
 
        NOCRLEALT
-
-                        Objects that should be skipped when building the
-                        alternative dependency mapping via the -d option.
-
+             Objects that should be skipped when building the alternative
+             dependency mapping via the -d option.
 
        NODIRECT
-
-                        Directories and files that are allowed to have no
-                        direct bound symbols.
-
+             Directories and files that are allowed to have no direct bound
+             symbols.
 
        NOSYMSORT
+             Files for which we skip checking of duplicate addresses in the
+             symbol sort sections.
 
-                        Files for which we skip checking of duplicate
-                        addresses in the symbol sort sections.
-
-
-       OLDDEP
-
-                        Objects that used to contain system functionality that
-                        has since migrated to libc. We preserve these
-                        libraries as pure filters for backward compatibility
-                        but nothing needs to link to them.
-
-
-       SKIP
-
-                        Directories and/or individual objects to skip. Note
-                        that SKIP should be a last resort, used only when one
-                        of the other exceptions will not suffice.
-
-
-       STAB
-
-                        Objects that are allowed to contain debugging
-                        information (stabs).
+     OLDDEP  Objects that used to contain system functionality that has since
+             migrated to libc.  We preserve these libraries as pure filters
+             for backward compatibility but nothing needs to link to them.
+
+     SKIP    Directories and/or individual objects to skip.  Note that SKIP
+             should be a last resort, used only when one of the other
+             exceptions will not suffice.
 
+     STAB    Objects that are allowed to contain debugging information
+             (stabs).
 
        TEXTREL
+             Objects for which we allow relocations to the text segment.
 
-                        Objects for which we allow relocations to the text
-                        segment.
-
-
-       UNDEF_OBJ
-
+     BUNDEF_OBJ
                         Objects that are allowed to be unreferenced.
 
-
        UNDEF_REF
-
                         Objects that are allowed undefined references.
 
-
        UNUSED_DEPS
-
                         Objects that are allowed to have unused dependencies.
 
-
-       UNUSED_OBJ
-
-                        Objects that are always allowed to be unused
-                        dependencies.
-
+     BUNUSED_OBJ
+             Objects that are always allowed to be unused dependencies.
 
        UNUSED_RPATH
+             Objects that are allowed to have unused runpath directories.
 
-                        Objects that are allowed to have unused runpath
-                        directories.
+     FORBIDDEN
+             Specifies that dependencies on a given object are forbidden.
 
+     FORBIDDEN_DEP
+             Specifies that a given object is permitted a forbidden
+             dependency.
 
 ALTERNATIVE DEPENDENCY MAPPING
        check_rtime was primarily designed to process a nightly builds $ROOT
        hierarchy. It is often the case that objects within this hierarchy must
        bind to dependencies within the same hierarchy to satisfy their

@@ -444,36 +411,33 @@
 
        To achieve this, check_rtime uses the shared objects specified with the
        -D or -d options.  If neither option is specified, and the $CODEMGR_WS
        and $ROOT environment variables are defined, the proto area for the
        workspace is used. The objects found are used to create runtime
-       configuration files via crle(1), that establish the new shared objects
-       as alternatives to their underlying system location.  check_rtime
-       passes these configuration files as LD_CONFIG environment variable
-       settings to ldd(1) using its -e option.
+     configuration files via crle(1), that establish the new shared objects as
+     alternatives to their underlying system location.  check_rtime passes
+     these configuration files as LD_CONFIG environment variable settings to
+     ldd(1) using its --e option.
 
        The effect of these configuration files is that the execution of an
        object under ldd(1) will bind to the dependencies defined as
        alternatives.  Simply put, an object inspected in the proto area will
-       bind to its dependencies found in the proto area.  Dependencies that
-       have no alternative mapping will continue to bind to the underlying
-       system.
+     bind to its dependencies found in the proto area.  Dependencies that have
+     no alternative mapping will continue to bind to the underlying system.
 
 ENVIRONMENT VARIABLES
        When the -D or -d option isn't in use, check_rtime uses the following
        environment variables to establish an alternative dependency mapping:
 
        CODEMGR_WS
            The root of your workspace, which is the directory containing
-           Codemgr_wsdata. Existence of this environment variable indicates
-           that $ROOT should be investigated.
-
-       ROOT
-           Root of the proto area of your workspace. Any shared objects under
-           this directory will be used to establish an alternative dependency
-           mapping.
+             .git.  Existence of this environment variable indicates that
+             $ROOT should be investigated.
 
+     ROOT    Root of the proto area of your workspace.  Any shared objects
+             under this directory will be used to establish an alternative
+             dependency mapping.
        If ldd(1) supports the -U option, it will be used to determine any
        unreferenced dependencies.  Otherwise ldd(1) uses the older -u option
        which only detects unused references.  If the following environment
        variable exists, and indicates an earlier release than 5.10 then ldd(1)
        also falls back to using the -u option.

@@ -481,22 +445,21 @@
        RELEASE
            The release version number of the environment being built.
 
 ERROR CONDITIONS
        Inspection of an object with ldd(1) assumes it is compatible with the
-       machine on which check_rtime is being run.  Incompatible objects such
-       as a 64-bit object encountered on a 32-bit system, or an i386 object
-       encountered on a sparc system, can not be fully inspected.  These
-       objects are displayed as:
+     machine on which check_rtime is being run.  Incompatible objects such as
+     a 64-bit object encountered on a 32-bit system, or an i386 object
+     encountered on a sparc system, can not be fully inspected.  These objects
+     are displayed as:
 
            foo: has wrong class or data encoding
 
 FILES
             $CODEMGR_WS/exception_list/check_rtime
+
             /opt/onbld/etc/exception_list/check_rtime
 
 SEE ALSO
-       crle(1), elfdump(1), find_elf(1ONBLD), ldd(1), ld.so.1(1), mcs(1).
-
-
+     crle(1), elfdump(1), ld.so.1(1), ldd(1), mcs(1), find_elf(1ONBLD)
 
-                                 March 9, 2010             CHECK_RTIME(1ONBLD)
+illumos                        February 19, 2018                       illumos