Building the LSB Application Battery

The LSB application battery (appbat) is built using a build tool in order to automate and standardize the process. The nALFS tool is driven by xml-style description files which capture the precise steps of building the appbat. In general, these steps are: unpacking, patching, configuring, building, installing to a temporary location, cleaning up. A separate step, outside of the xml, then uses rpm to package the temporary install location into an lsb-conforming package. Rpm is not used to drive the build process itself as the rpm build rules may vary across distributions, and some distributions are not set up to use rpm for package building.

This page will explain the steps necessary for setting up the build environment and actually building the appbat packages.

Obtain and Install Build Tools

The appbat is built using the lsbdev build tools. Binary rpm-format packages are produced for each supported LSB architecture. Deb-format packages can also be built from the sources, but are not released by the LSB project. Obtain and install the appropriate architecture and format packages.

For building under LSB 2.0/3.0 you will need:

• lsb-build-base: headers and stub libraries
• lsb-build-cc: C and C++ front-end drivers
• lsb-build-c++: C++ headers

The path to the build tool, /opt/lsb/bin, needs to be added to your PATH environment variable before starting up the build.

Obtain Source from CVS

The appbat sources consist of two general components: the build tool, xml descriptions, patches and other supporting files which are checked into the LSB project CVS repository; and the original source bundles. Included in the CVS files is a tool which will download the source bundles from the appropriate upstream locations. The following CVS modules are required to build the appbat:

To find out how to access the CVS repository, see Version control on the Wiki.

Configure Build Area

The appbat directory contains a configuration script to localize the build. Some of the xml, as well as the package checker/retrieval tool, need to know a little about the build environment. Change directory to appbat and run ./configure, answering the questions. You have the opportunity to point to an existing directory of source bundles if there is one; if not, just accept the default and proceed to the next step. See Build Dependencies below if the configure script fails.

Retrieve Source Bundles

The appbat files include a tool which can check for the presence of the necessary source bundles and patches, and that they are the correct versions (by checksumming against a master list). If the sources have been freshly checked out, the source bundles will not be present. Run the command make update to initiate the process of checking for and downloading the necessary packages. The files will be fetched using a combination of HTTP and FTP protocol; if you need to use a proxy for these the syntax to set this up is as follows (note that complex setups are likely to still fail - it's a wishlist item to handle this better):

export http_proxy=host:port
export ftp_proxy=host:port

If the tool is not able to retrieve the source bundles, you will have to do this manually. For convenience, all of the bundles are mirrored on the linux-foundation.org website: http://ftp.linux-foundation.org/pub/app-battery/packages. Use the package checker output to see what packages are missing (it is not necessary to retrieve all the packages in the mirror). If necessary, rerun the checker in check mode (as opposed to update mode) to regenerate the list: make check

Build Dependencies

Certain applications may require header files or static libraries that are not present on the build host. For example, the xpaint application requires the xpm.h header file and the libXaw.a static library. Building an accurate dependecy table is not easy: nALFS doesn't have any explicit dependency checking, although rules could be added to the xml, and it's hard to tell what to depend on. For the above example, across various distributions the library and header are not always in the same package, and since no specific packaging scheme is required of an LSB system, it's not possible to, for example, use rpm to check if the dependency package is installed. So at the moment, resolving dependencies is a part-manual process. The configure script checks for the dependencies it knows about at file/library level, and reports on these (it will fail to configure if something key is missing). You will still need to work backwards to find the right packages to install.

Here are some of the dependencies:

• expat, ncurses development - needed for nALFS which is not built as an LSB application
• yacc (perhaps provided by bison) - needed to build groff
• xfree86 development - xpaint, xpdf, Celestia (lsbdev does not include X11 headers today, and some static archives may be needed)
• freetype development - xpdf
• GL, GLU development - celestia
• t1lib development - xpdf

Some of the static-library dependencies can also be met by installing the unofficial lsb-build-libbat package (check the unreleased directory for this); the LSB project uses this package for building, and it can itself be built as an optional part of the appbat build process.

Create LSB Runtime Linker

If the system being used does not already have an LSB runtime linker, then it must be created. While it's not strictly necessary to have an LSB-conforming runtime in order to build LSB conforming programs, the build process of several of the appbat programs uses the built binary to complete the build and/or install process, so the build host must indeed be able run LSB programs to compile the appbat. The easiest way to solve this dependency is to use an LSB-conforming runtime. If this is not possible, it is usually sufficient to create the LSB runtime linker as a symbolic link to the Linux runtime linker. For LSB 2.0 (on ia32):

ln -s /lib/ld-linux.so.2 /lib/ld-lsb.so.2

For LSB 3.0 (on ia32):

ln -s /lib/ld-linux.so.2 /lib/ld-lsb.so.3

The name of the LSB and Linux linker varies by architecture, the above example works for the ia32 architecture only.

Build Applications

With all the setup completed, you are now ready to build the appbat applications. A Makefile will drive the build, including building the nALFS tool if needed. At a given time, there may be two categories of applications in the appbat. There will always be a set of applications that are to be used as part of the LSB certification and self-certification programs. These can be built using "make appbat" (this is also the default target). If the build is interrupted for any reason, it can be resumed using "make appbat-restart". Note that running "make appbat" after interruption will restart the build from the beginning.

There may also be another class of applications in the appbat: ones which either are being evaluated for addition to the certification programs, or which are not intended for inclusion in the program. To build these applications, run "make addons" or "make addons-restart".

It is possible to build both sets using "make everything" or "make everything-restart".

Build results will be logged to a .nALFS subdirectory of your home directory. Check the file status.log.

To build individual applications, it is best to invoke nALFS in interactive mode:

../tools/nALFS/nALFS -l appbat.xml

Use the cursor keys to move up/down; the ENTER key to open a cascaded item (plus sign at the left). nALFS accepts single character commands at this point. Enter "s" to "(s)tart running" the profile. At the next prompt enter "c" to build the "element and it's (c)children". It's best to start a package build at its' top level line, otherwise the restartability code will get in the way, however for debugging it is certainly possible to run the "Prebuilding", "Building" and "Postbuilding" steps individually. If doing so, it will be necessary to remove a file of the form /tmp/alfs.package.ckpt in between steps.

Packages are extracted and built in the build subdirectory. As they complete building, they are installed underneath the pkgroot subdirectory, and the build directory is removed.

Build Binary RPMs for Applications

Now that all the applications have been built the next step is to package them into proper RPM format. This can be done by changing to the rpm subdirectory and running "make". This will package all the apps into RPM format and place the resulting files in the rpm/architecture directory.

Install Appbat Applications

At this point the RPMs in the rpm/architecture directory can be installed by root. The applications will install into/opt/lsb-appname directories in accordance with the FHS.

Please send any feedback to lsb-discuss_at_linux-foundation.org