SYNOPSIS
lsbappchk [-hvnj] [-T PRODUCT] [-M MODULE]... [-L LIB]... [-D DIR]... [-o OUTPUT-FILE] [long-options] appnamelsbappchk [-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.