From The Linux Foundation

Using the LSB Developer Packages

The LSB Developer (lsbdev) packages help you develop LSB applications. In particular, they let you build your program in a way which makes it harder to pick up non-LSB functionality.

Lsbdev actually is not one but two ways to point your application at the LSB bits, lsb-buildenv and lsbcc. Each has its advantages (and disadvantages). This page will describe both.

About the lsbdev packages

With lsbcc, you tell your build system to compile with lsbcc instead of the usual C compiler (gcc, cc, c89 or some such). For example, programs with GNU-style configure scripts can probably just use CC=lsbcc ./configure. lsbcc is the quickest way to try building a conforming application, and is useful if the build will require various other software that may be installed on the system. Since non-LSB libraries, except those supplied with the application, must be statically linked, lsbcc automatically transforms the command line to arrange this before passing it on to the regular C compiler. This means you need to make sure the necessary static libraries are installed - many systems by default install only the dynamic versions. The downside of lsbcc is that it is easier to fool; complex build procedures, especially those that use a tool (such as libtool or pkg-config) to locate elements to link, will often bypass lsbcc's rewriting rules.

With lsb-buildenv, you chroot to run in a restricted environment which excludes most of the non-LSB functionality. lsbdev-buildenv is a safer way to build conforming binaries, as it's almost impossible to pull in non-LSB components by accident. The downside is that many builds require additional software beyond what is in the LSB for building, and setting this up will be a bit more work. However, this setup usually only needs to be done once.

Since no build tool can do a perfect job at assuring LSB conformance, a test tool is also provided. [#lsbappchk See below] for more details.

Using the lsbdev packages

Both build systems require the lsb-build-base package, which contains the header files and libraries that will be used during building. This is pre-installed into the lsb-buildenv package as delivered.

Using lsb-buildenv

The lsb-buildenv code is not included in the SDK for size reasons (the package is nearly 500 meg), but may be found here.

XXX add setup instructions here

Using lsbcc

The easiest way to get started is to download the SDK which contains all the packages and an installation script.

• Add the path /opt/lsb/bin to your PATH.
• Tell your build system to use lsbcc instead of the usual C compiler. For example, if your program uses a GNU-style configure script, "CC=lsbcc ./configure" may well just work.
• If your application contains C++ code, you may be able to get it to work by specifying lsbc++ as the C compiler. For GNU configure scripts, the sequence may look like "CC=lsbcc CXX=lsbc++ ./configure".

Available Tools

lsbappchk

lsbappchk examines a binary and reports on problems with LSB conformance. Partially redundant if you built with the lsbdev tools, but may find some things which slipped through the cracks. May also be useful as a first approximation of porting effort if run against a native binary.

$ /opt/lsb/bin/lsbappchk program

Note note that if non-LSB libraries are dynamically linked into the native binary, all interfaces used from those libraries, as well as the libraries themselves, will be reported on as LSB violations. System libraries need to be statically linked if they are not part of the LSB. Application-supplied libraries may be linked dynamically as long as the library will be provided with the application, or by another LSB-conforming application. These libraries can be eliminated from the lsbappchk output by using the -L option to supply a path to each such library.

Development Libraries and Headers

A set of libraries that should be used for linking LSB applications is provided by the lsb-build-base package in the directory /opt/lsb/lib (lib64 for 64-bit platforms). These libraries contain only the interfaces that are specified by the LSB. Linking against these libraries can help detect the use of non-LSB interfaces earlier in the development process. lsbcc and the lsb-buildenv automatically add a path to these when compiling.

lsb-build-base also provides a set of development headers in /opt/lsb-base/include. These headers increase the chance of a clean build by excluding non-LSB elements from standard header files. These headers are also used automatically when building with lsbcc or lsb-buildenv.

lsb-build-desktop provides additional libraries and headers for the desktop specification - these are packaged separately to make clearer that they are the difference between LSB 3.0 and LSB 3.1.

Three additional packages, lsb-build-c++, lsb-build-qt3 and lsb-build-qt4 provide additional headers needed for those environments. They are packaged separately since they are not generated by the LSB project, but instead are captured from the "upstream" package as a snapshot.

lsbpkgchk

Use to check the validity of an rpm package made of an LSB application. Reports on unexpected dependencies and any formats not described by the LSB spec - these may cause installation problems since LSB platforms are only requried to accept packages in the correct format.

$ /opt/lsb/bin/lsbpkgchk pkgname.rpm

See also

• LSB Build Environment
• Man page for lsbappchk(1)
• Man page for lsbcc(1), distributed with lsb-build-cc.