lsbappchk3

Langue: en

Version: 262781 (debian - 07/07/09)

Section: 1 (Commandes utilisateur)

NAME

lsbappchk - check LSB conformance of application or shared library

SYNOPSIS

lsbappchk [-hvnj] [-T PRODUCT] [-M MODULE]... [-L LIB]... [-D DIR]... [-o OUTPUT-FILE] [long-options] appname
lsbappchk [-hvnj] [-T PRODUCT] [-M MODULE]... [-o OUTPUT-FILE] [long-options] -L LIB

DESCRIPTION

In the first form, measure an application executable's conformance to the Linux Standard Base (LSB) specification. The object format of the application is checked, as is the list of shared libraries used by the application, and the list of functions and global data used by the application. Warnings are produced for anything that is referenced but not contained in the LSB specification. lsbappchk's view of valid libraries and interfaces can be expanded.

In the second form, a shared library is examined individually, rather than in the context of a binary linked with it. This is useful for shared libraries that may be development targets on their own.

-h, --help
Print a help message and exit.
-v, --version
Output the program version and LSB version to standard output. The version and LSB version are always logged to the journal file irrespective of this option.
-j, --journal
Create a journal instead of a human-readable report.
-n, --no-journal
Do not create a journal file.
-r VERSION, --lsb-version=VERSION
Specify the lsb version the application should be checked against.
-T [core,c++|core,c++,desktop], --lsb-product=[core,c++|core,c++,desktop]
Specify the lsb spec/product to load modules for - 3.0, and 3.1, respectively.
-M MODULE, --module=MODULE
Also check the symbols found in MODULE. The default module name is LSB-Core. Other choices are LSB-Graphics and LSB-C++ (module names are not case-sensitive).
-L LIB
Specify the full pathname of a shared library which is part of the application. This option can be specified as many times as needed, and will prevent lsbappchk from complaining about symbols which are provided in those shared libraries. The order of libraries specified this way is significant: since lsbappchk does not actually run the application, it cannot deduce the library dependency graph.
This option may also be used if a shared library needs to be checked standalone.
-D DIR, --shared-libpath=DIR
Specify a full directory path to search for shared libraries which are part of the application. Any libraries found under this path are treated as if they had been added with the -L option.
-o OUTPUT-FILE, --output-file=OUTPUT-FILE
Write the journal file or report to OUTPUT-FILE instead of to the default filename in the current directory (or to standard output for reports).

With the -j option, a journal file named journal.appchk.appname is created, where appname is the binary specified on the command line. It contains a record of the test results in a format that can be submitted for LSB Certification. You must have write access to the current working directory in order to run lsbappchk successfully, or use the -o option to specify an alternate location for the journal. Journal files may be examined with the tjreport tool, available from the LSB project as part of the lsb-tet3-lite package.

Without the -j option, a text report is printed to standard output, or to the file specified with the -o option.

If there are several related binaries in a package build, lsbappchk may be called with multiple names on the command line, producing a single journal file, or it may be called multiple times to produce individual journal files. In the former case, the default journal name will include the name of the first binary specified.

The lsbappchk program cannot detect all conformance problems. In particular, it is a static test and does not actually run the application. lsbappchk will not find any behaviors which show themselves only at run-time (for example, anything involving the File Hierarchy Standard, or constants and other such items which are found in header files). lsbappchk will warn that it cannot determine the validity of a call to ioctl. The dynamic checker (lsbdynchk) should be used to test run-time behavior.

NOTES

lsbappchk is intended to be used on applications compiled in LSB mode. When used as an analysis tool on non-LSB applications, it will report false negatives, such as symbols with the wrong symbol version, which will vanish when the application is compiled correctly. Recognizing which reports can be ignored requires detailed knowledge of the LSB and of the libraries in question.

AUTHORS

The contributors to the Linux Standard Base.

REPORTING BUGS

If you obtained this checker from the LSB ftp site, report bugs at http://bugs.linuxbase.org or email to <lsb-discuss@linux-foundation.org>. If you obtained this from your distribution, report bugs back to the distribution in the normal way.

SEE ALSO

Linux Standard Base specification and other documents at http://www.linux-foundation.org/