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/