Porting to the LSB Demo

Printer-friendly version

Because Linux is an open operating system, you can configure and assemble it to suit specialized purposes. However, while variety and choice are beneficial for users, heterogeneity can vex software developers who must build and support packages on a multitude of similar but subtly different platforms. Fortunately, if an application conforms to the Linux Standard Base (LSB) and a flavor of Linux is LSB compliant, the application is guaranteed to run. Discover the LSB, and learn how to port your code to the standard.

This tutorial describes the Linux® Standard Base (LSB), a specification and collection of tools and test suites that help Linux software developers increase compatibility among Linux software distributions. Applications and distributions can be certified compliant with the specification, providing assurances to users that certified software is compatible. This tutorial describes the LSB and explains how to vet your application code to conform with it.

Prerequisites

To benefit from this tutorial, you should have experience with the C or C++ programming language as well as the typical Linux software development environment and its cadre of tools, including the compiler, linker, system libraries, configuration and build utilities, and packaging tools.

You should also have experience installing software from the command line and have at least a modicum of experience with administering and maintaining a Linux system, such as configuring a file system, starting and stopping network services, and adding system services.

If you're running Debian Linux, you should also have some experience with the APT package manager.

Before you start the tutorial, you must install several software packages on your Linux system. Here's everything you need:

The KVM package for your Linux distribution
Note: Alternatively, you can easily install VMWare Workstation on any computer running Microsoft® Windows® XP and run a virtualized Linux instance on the Windows XP platform. Download a trial version of VMWare Workstation at no cost and use it to create one or more virtual machines (VMs). After you've created a VM, you can save it and switch to the free VMWare Player to replay it.
The LSB Sample Implementation
The LSB Build Environment
The LSB application test suites

You may also find it useful to download and read the LSB V3.2.0 specification appropriate for your target hardware platform. Hardware-specific LSB specifications are available for seven popular architectures: the IA32, IA64, PPC32, PPC64, S390, S390X, and AMD64 processors.

If you want to certify your application, please visit the Linux Foundation's LSB Certification Program.

To run the examples in this tutorial, you must have a computer running either the Linux or Windows XP operating system. VMWare Workstation running on either of those platforms provides a Linux environment for you to do the rest of your work.

If your application depends on software libraries other than those ratified as part of the LSB specification for your processor, you must install those libraries on the virtual system, as well. To avoid confusion, it's ideal to install application-specific libraries separately from the standard libraries.

The Need for a Standard

According to the DistroWatch Web site, at least 25 significant Linux distributions currently exist. If you include other variations -- some optimized for size (such as Damn Small Linux), some for convenience (such as Knoppix), some tailored to a specific audience (such as Fedora Core), and still others customized for a specific country (such as Red Flag Linux)--that rather staggering number of choices easily doubles or triples. Linux is the only modern operating system with such numerous variations.

On one hand, the do-it-yourself culture of Linux encourages diversity and specialization. On the other hand, such proliferation can be overwhelming, especially if you're an independent software vendor (ISV) faced with developing, selling, and supporting a Linux application. If the "UNIX® Wars" of the 1980s splintered ISVs' chances of success, so many Linux versions seem to promise nothing less than wholesale obliteration of the market for rich Linux applications. To wit, imagine the expense of building and supporting a complex application on more than a handful of Linux variants.

LSB Terminology

When discussing the LSB, you'll frequently hear (and read) the terms conformance, compliance, and certification:

The LSB defines requirements for a run time and an application to be in conformance with the specification.
An application or a distribution is in compliance with the LSB if its developer has realized all the suitable LSB requirements and claims that the software conforms.
An application or distribution receives certification if it successfully demonstrates compliance through official review.

In this tutorial, you learn how to create compliant applications. You cannot self-certify your application, although you can run many tests that greatly increase the likelihood of certification.

Promoting Interoperability

In an attempt both to encourage diversification and provide consistency, the Free Standards Group (now The Linux Foundation) created the Linux Standard Base, an "open source project to develop and promote a set of standards [to] increase compatibility among Linux distributions and enable software applications to run on any compliant system" (according to the LSB Web site).

Specifically, the LSB defines a consistent Linux platform. A Linux distribution is LSB compliant if it implements (at least) the LSB platform. (Nothing precludes a version of Linux from providing additional features.) A Linux application is LSB compliant if it consumes only the services that the LSB platform provides. If the application requires additional libraries, it provides those, either during installation or through static linking. (Of course, the libraries must be self-sufficient and LSB compliant, as well.) The sidebar "LSB terminology" explains what other terminology means.

The figure below shows the many areas for which the LSB defines (or will eventually define) standards. The areas are libraries, the basis of all Linux applications; the execution environment, including mandates for where certain critical system files reside and how the system provides for localization services; system initialization; common commands and utilities to be found across all LSB-compliant systems; and user and group management.

Figure 1. The Components of the LSB

Application developers are probably most concerned with the blue and orange boxes.

In blue, the LSB stipulates a set of core libraries and additional modules that an LSB-compliant application can use. The core libraries include libc, libm, libpthread, libpam, libcrypt, libz, libncurses, librt, and libgcc_s. Modules include a module for X Window System Version 11 graphics (libX11, libXt, libXext, libSM, libICE, and libGL) and the C++ standard library, libstdc++.

In orange--and not part of the LSB specification--is a set of valuable companion tools to validate that applications, packages, (and soon, static libraries) are LSB compliant.

Binary Compatibility

The LSB specification is a binary compatibility standard. An application binary (compiled, executable code) that is LSB compliant can run unchanged on any LSB-compliant Linux distribution (built for the same processor architecture as the application).

Binary compatibility is remarkably different from source compatibility. An application that is source compatible requires the software to be recompiled in situ, with the local system's compilers and libraries--two significant founts of variability and unpredictability. Source compatibility doesn't guarantee that the executable will run, let alone run as expected.

The Benefits of Consistency

Think of the LSB as a kind of binding agreement between a distribution and an application. The distribution "agrees" to provide (at least) the specification's libraries and interfaces, and the application "agrees" to use only those libraries and interfaces, providing any other software that's needed. To ensure that "both parties" adhere to the agreement, the LSB provides tools, guidelines, and validation services to certify Linux distributions and applications as LSB compliant.

Adherence to the LSB inures to the benefit of distribution vendors, ISVs, and users alike.

For the distribution vendor:

A distribution vendor can promote compliance with the LSB, assuring customers that LSB compliant applications will run consistently and reliably on its product.
After its distribution is certified LSB compliant, a vendor can re-focus its energies on differentiating, novel features.

For the ISV:

An application developer can create and certify a single binary and deploy it to any LSB-compliant distribution.
An ISV need only test and support the single, certified binary. Additionally, if the binary is sufficiently internationalized, a single version of an application might suffice for all customers, independent of nationality.

For the customer, the user:

The user can pick and choose among competing LSB-compliant distributions, either to deploy the most appropriate flavor of Linux or to avoid vendor lock-in.
The user has many Linux applications to choose from.

Given all the dynamics listed above, distribution vendors, ISVs, and users reap rewards from each unique investment in Linux. In turn, Linux benefits, as well.

The LSB Build Environment and Sample Implementation

The LSB is a "contract" between an application and a distribution to adhere to the LSB specification. Ignoring the complications of making a Linux distribution compliant, how can a Linux application developer--you--ensure compliance?

If you're a developer, you likely know your code very well and can work diligently to meet the obligations of LSB compliance. However, it may not always be obvious that your code depends on a non-standard (non-LSB) component, especially as a typical Linux distribution has thousands of components strewn about the system.

For example, perhaps your code depends on a non-compliant string library found only on your favorite distribution. Or perhaps, the string library used was added locally and recently by your system administrator. As an another example, perhaps your code depends on a specific version of a library. Version W of the library is LSB compliant, but version Y--the version you depend on--is not part of the LSB specification.

Tools to Help You Migrate

To help find and remove such dependencies--the crux of making your code LSB compliant--the LSB provides two significant tools: the Build Environment and the Sample Implementation.

The Build Environment helps you identify source code that depends on non-LSB libraries and application binary interfaces. The Build Environment consists of header files, stub libraries, and a compiler wrapper that simulate a software build environment on a compliant Linux system. You can install the Build Environment on any Linux system--even one that is not compliant.

The Build Environment is available in two forms: One form is a set of utilities that run within your local operating system. The utilities simulate a build within an LSB environment. The other form is a complete hierarchy of files that substitutes for your environment with chroot. You might use the former as a quick measure of compliance. The latter typically requires you to import your build environment into the new root, but eliminates issues with stray files.

The Sample Implementation helps you validate that your application executes successfully in a compliant run time environment. You can think of the Sample Implementation as a mini-Linux (yes, you can boot from it, if you want to)--an environment that proxies for an LSB-compliant distribution.

Of course, you could use an LSB-compliant distribution as your test environment, but the Sample Implementation has a few advantages: It only includes what's defined in the LSB, and several versions of the Sample Implementation exist--one each for version of the LSB specification. Hence, if you want to verify that your application is LSB V3.0 and LSB V3.2 compliant, you can install the respective Sample Implementations on a single test system rather than require two Linux systems. Certainly, the Sample Implementation is the preferred method to validate your application against a newly ratified LSB specification before real-world, compliant systems are available.

An individual Build Environment and Sample Implementation set is provided for each version of the LSB standard. For this tutorial, you'll use LSB V3.2.0 as the target platform. (Version 3.2.0 was the most recent LSB specification at the time this tutorial was written. Versions 3.1.0 and 3.0.0 are previous versions of the LSB. You'll likely find that many popular Linux distributions are certified with either of the earlier instances of the LSB.)

The Benefits of Porting Using Virtual Machines

To run the LSB V3.2.0 Sample Implementation, you need an operating system capable of running the Sample Implementation in a chroot environment. The community distribution Fedora 9 (aka FC9) is one flavor of Linux that can run the V3.2.0 Sample Implementation, which we will use for the purpose of this tutorial.

But what if you don't have FC9 installed? Or, what if you want to run your application on numerous instances of the LSB or on a handful of Linux distributions? You could assemble a (somewhat large) collection of hardware or multi-boot among all your desired variations, but a far easier and less-expensive solution is to run each Linux distribution in its own VM.

KVM is a virtualization technology which is supported on most modern distributions, including Ubuntu Hardy. It does require a relatively new x86 CPU that supports the Intel-VT or AMD-V (also called the AMD SVM extensions). A list of which CPU's support (or do not support) these extensions can be found on this web page maintained by Xensource. On some systems, the virtualization extensions have to be enabled via a BIOS configuration awitch, and may require a complete power cycle after changing the BIOS configuration and saving the configuration to flash.

If your Linux system does not support KVM, or if you wish to run this tutorial on non-Windows sytem, such as a Windows XP system, it is possible to download and install VMWare instead. You will need to use a Fedora Core 9 image from the Thought Police web site.

Download and Install VMWare Workstation

Install VMWare Workstation on Debian Linux, and run FC9 in a VM to run the LSB V3.2.0 Build Environment and Sample Implementation.

Download a VM Image

You can download a FC9 VM image from the Linux Foundation web site. As this image contains an entire operating system, it's quite large: 1400MB.

Installing KVM

If you are running Ubuntu Hardy system, installing the is as simple as installing the KVM package. This can be done by using the command:

sudo apt-get install kvm

in a terminal window. Or, you can use the Synaptics package manager if you prefer using a graphical interface.

As packaged in the Debian and Ubuntu distributions, in order to use kvm without being root, your user id must be in the "kvm" group. You can edit the /etc/group via a text editor as the superuser, or if you are running Ubuntu, you can use the menu selection System->Administration->Users and Groups from the system's menubar, and then on the click on the "Unlock" button, enter your password, then click on "Manage Groups". This will cause a "Group Settings" window to appear. Find "kvm" in the selection window, and then click on "Properties", and then add a check-mark next to your user id in the "Group Members" list, and then click the "OK" button. After you make a change to the group membership of the "kvm" group, you will need to logout and then login again so the change can take effect.

Running KVM Workstation

To start the KVM virtual machine you simply run the following command in a terminal window:

kvm fedora-9-i386.qcow2

The KVM application traps all mouse and keyboard input unless you press Ctrl+Alt. To set the focus back to the virtualized environment, just click in the KVM window.

Congratulations! You now have FC9 running in its own VM!

Porting Your Code to the LSB

With setup behind you, you can begin the process of porting your code to the LSB.

The General Approach to Porting

Porting an application to the LSB requires the following steps:

Copy your code to the new build system.
The new build system might be an LSB-compliant Linux distribution running on separate hardware or, in this case, a VM.
Build your code, and run the Linux Application Checker ("AppCheck") tool to scan your binary for symbols that are not expressly provided in the LSB specification.
You can also this tool to scan your static archives for suitability for use in an LSB-compliant application.
If AppCheck finds invalid symbols, change your code or the assembly of your code to bring it into compliance.
For instance, if you're using a library that isn't part of the LSB specification, link to it statically so that the code is self-contained in your binary. (Again, this assumes that the code in the library itself is otherwise LSB compliant.) Assuming that you've addressed all the issues, you can proceed to the next step.
Use the LSB Build Environment to build the code in a clean, compliant environment.
If your code uses libraries that are not provided for under the LSB, you must modify your build process to either install or link statically to those libraries. (Remember that all libraries must be LSB compliant, as well.)
If your code builds successfully within the LSB Build Environment, run the code in the LSB Sample Implementation.
If your target Linux system is LSB compliant, run your code on that system.
Package your application.
LSB-conforming systems promise to be able to install an LSB-compliant RPM. However, you need not limit yourself to that format, with the caveat that the packaging technology you choose must work on an LSB-compliant system. For example, a shell script with a tarball is an acceptable format. Your own installer is acceptable, too, as long as the installer itself is LSB compliant.

Now, let's build a simple application to elaborate on the process.

Installing and Running the LSB Build Environment Utilities

Before using the chroot version of the LSB Build Environment, try the Build Environment utilities, which you can quickly and easily install on virtually any Linux system. You can use the Build Environment utilities lsbappchk and lsbpkgchk to quickly determine why your application and RPM package (the standard LSB format), respectively, aren't compliant with the LSB.

Download and Install the Build Environment Utilities

The Build Environment utilities are available as two RPMs, one for lsbappchk and another for lsbpkgchk. Because the test system is Debian Linux, convert the RPMs to DEB format, which is suitable for Debian's dpkg package manager:

1 $ sudo apt-get install wget

2 $ wget http://ftp.linuxfoundation.org/pub/lsb/test_suites/released-3.2.0/binary...

3 $ wget http://ftp.linuxfoundation.org/pub/lsb/test_suites/released-3.2.0/binary...

4 $ wget http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia32...

5 $ wget http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia32...

6 $ wget http://ftp.linux-foundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia3...

7 $ sudo apt-get install alien
8 $ alien *.rpm
9 $ ls -t -1
lsb-pkgchk_3.2.2-2_i386.deb
lsb-build-cc_3.2.1-1_i386.deb
lsb-build-c++_3.2.1-1_i386.deb
lsb-build-base_3.2.2-1_i386.deb
lsb-appchk_3.2.4-1_i386.deb
lsb-pkgchk-3.2.2-2.i486.rpm
lsb-appchk-3.2.4-1.i486.rpm
lsb-build-c++-3.2.1-1.i486.rpm
lsb-build-cc-3.2.1-1.i486.rpm
lsb-build-base-3.2.2-1.i486.rpm
10 $ sudo dpkg --install *.deb
11 $ ls /opt/lsb
bin  doc  man
12 $ ls /opt/lsb/bin
lsbappchk  lsbc++  lsbcc  lsbpkgchk

Command 1 installs wget if it isn't already available on the system. Commands 2-6 download the latest versions of the LSB utilities:

Lsb-appchk verifies that a supplied binary only uses the dynamically linked symbols defined in the LSB.
Lsb-pkgchk verifies that an application package--a bundle used to install the software on an LSB-compliant system--is valid. The lsb-pkgchk tool is intended for RPMs only. However, the LSB does not mandate the use of RPMs to install software.
Lsb-build-base provides stub libraries and header files. While the stub libraries don't implement the functions defined in the LSB, they do mimic the actual dynamic libraries found on an LSB system. Hence, you can use lsb-build-base to build a compliant application.
Lsb-build-c++ adds C++ support to the build environment.
Lsb-build-cc contains lsbcc, a wrapper around the CNU Compiler Collection (GCC) compiler that yields LSB-conforming applications. If your application uses a GNU-style configure script, you can easily modify your script to use lsbcc instead of the default system (typically GCC) CC compiler. In some cases, you can directly replace GCC with lsbcc (for example, in a makefile).

Command 7 installs alien, a utility that can convert RPMs to Debian DEB packages (among other features). Command 8 runs alien; command 9 shows the results; and command 10 installs all the software into the /opt/lsb/ directory, as shown in commands 11 and 12.

Building and verifying an RPM is beyond the scope of the tutorial. Instead, let's focus on building a small C application with lsbcc and scanning the resulting binary for invalid symbols with lsb-appchk.

An Example Program

Listing 1 shows a small program that echoes its command-line arguments (error-checking code has been omitted intentionally).

Listing 1. A Simple C Program

#include <stdio.h>
#include <unistd.h>

main(argc, argv)
int argc;
char *argv[];
{
  int i = 0;

  for (i = 1; i < argc; i++) {
   fputs(argv[i], stdout);
   putchar(' ');
  }
  
  putchar('\n');
  
  exit(0);
}

Copy and paste the code into a file named echoargs.c, and then build it with the compiler installed on your Debian system:

$ cc -o echoargs echo.c 
$ ./echoargs hello there, world!
hello there, world!

The code works as intended, but is it LSB conforming? To make the determination, run the lsbappchk command:

$ /opt/lsb/bin/lsbappchk echoargs
Checking binary echoargs
Incorrect program interpreter: /lib/ld-linux.so.2
Header[ 1] PT_INTERP       Failed
Found wrong interpreter in .interp section: /lib/ld-linux.so.2 instead of: /lib/ld-lsb.so.3

Echoargs is clearly not an LSB-conforming application.

Use the LSB Compiler to Make the Application Conform

Now, rebuild the same code using the LSB compiler--lsbcc--and run lsbappchk on the binary it produces:

$ /opt/lsb/bin/lsbcc -o lsb-echoargs echoargs.c
$ /opt/lsb/bin/lsbappchk lsb-echoargs
Checking binary lsb-echoargs

Much better! The new binary is conforming. It was built with the LSB stub libraries using the LSB include files (header files) instead of the system header files. But does the application run?

$ ./lsb-echoargs
-bash: no such file or directory: ./lsb-echoargs

Unfortunately, the example system, Debian Sarge, is not LSB V3.2 conformant, so the binary cannot be executed. The command ./lsb-echoargs produces the somewhat odd message, -bash: ./lsb-echoargs: No such file or directory, which belies the real error--namely, that the system cannot load the binary. (In a moment, you'll use the LSB Sample Implementation to run this binary.)

As another example, consider Listing 2. The code snippet uses the open source Perl Compatible Regular Expressions (PCRE) library to add the power of regular expressions to traditional C. As useful as PCRE is, it's not part of the LSB specification.

Listing 2. A Snippet of a PCRE Application


#include <pcre.h>
..

int main()
{
  pcre *re;
  const char *error;
  int erroffset;

  ...
  
  re = pcre_compile("^[A-Z]", 0, &error, &erroffset, NULL);

  ...
}

Assuming that LD_LIBRARY_PATH includes /usr/local/lib, you can build the code with the command cc -o pcre pcre.c -l pcre.. Checking the code with lsbappchk produces an additional error message:

$ cc -o pcre pcre.c -l pcre
$ /opt/lsb/bin/lsbappchk pcre
Incorrect program interpreter: /lib/ld-linux.so.2
Header[ 1] PT_INTERP       Failed
Found wrong interpreter in .interp section: /lib/ld-linux.so.2 instead of: /lib/ld-lsb.so.3
DT_NEEDED: libpcre.so.0 is used, but not part of the LSB
Symbol pcre_compile used, but not part of LSB_Core

The functions declared by PCRE are not LSB compliant and are flagged. You could avoid this error (assuming that the rest of the PCRE library was LSB compliant) by adding the -static flag.

Interestingly, the same command using lsbcc does not generate errors:

$ /opt/lsb/binlsbcc -o pcre pcre.c -l pcre
$ /opt/lsb/bin/lsbappchk pcre
Checking binary a.out
$ nm a.out | grep pcre
0809b680 R _pcre_OP_lengths
0809b900 R _pcre_default_tables
0809b6d4 R _pcre_utf8_table1
0809b6ec R _pcre_utf8_table1_size
0809b6f0 R _pcre_utf8_table2
0809b708 R _pcre_utf8_table3
0809b720 R _pcre_utf8_table4
0809b760 R _pcre_utt
0809b888 R _pcre_utt_size
080b385c B pcre_callout
0804b0a0 T pcre_compile
0804b0e0 T pcre_compile2
080b18e4 D pcre_free
080b18e0 D pcre_malloc
080b18ec D pcre_stack_free
080b18e8 D pcre_stack_malloc

Here, lsbcc statically linked the PCRE code into the executable -- one solution to avoid library differences between one Linux platform and another. Lsbcc modifies command-line arguments to the GCC compiler to use LSB header files and libraries and to avoid dynamic links to non-compliant LSB libraries.

If you use GCC and a number of home-grown or popular tools to build your code, lsbcc is probably preferable over the chroot LSB Build Environment. In contrast, if you use a compiler other than GCC or have dependencies on a specific compiler, compiler options, or library or include file paths, the LSB Build Environment is superior. The next section demonstrates how to install and use the LSB Build Environment.

Installing the LSB Build Environment and Sample Implementation

Note: The rest of this tutorial uses the virtual FC9 instance running in VMWare Workstation. If you previously suspended the FC9 VM or quit VMWare Workstation, resume the FC9 VM or re-launch VMWare Workstation and start the FC9 instance. When the instance is running, log in as root.

The LSB chroot Build Environment lets you build your application in a box, or a specific, well-controlled, isolated environment. You download the chroot Build Environment, install it, and then expand the Build Environment with whatever utilities, libraries, and sources you need to build your application. Once configured, you use the chroot command to change the effective root filesystem to the Build Environment, which ensures that no files except those found in the Build Environment root are visible.

Download and Install the chroot Build Environment

You can download the version 3.2.0 Build Environment from the LSB download page . The chroot Build Environment is distributed as multiple RPMs.

At the root prompt, create a temporary directory. Use cd to go to that directory, and then run the following commands (wget is already available in the FC9 VM that you installed; long lines have been continued over multiple lines using the backslash to meet production requirements):

$ wget http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia32...
$ wget http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia32...
$ rpm -i lsb-build-base-3.2.2-1.i486.rpm 
$ rpm -i lsb-build-cc-3.2.1-1.i486.rpm

Installing the RPM yields a new directory, /opt/lsb-buildenv-ia32/. Its contents should look familiar:

bin  boot  dev  etc  home  lib  media  mnt  
opt  proc  root  sbin  srv  tmp  usr  var

To use the directory as an isolated environment, run chroot /opt/lsb-buildenv-ia32 /bin/bash. You should be prompted with a new shell prompt, bash-3.00#. If you navigate around the file system, the only files visible are those in /opt/lsb-buildenv-ia32/, now the effective /, or top-level directory.

For now, press Ctrl+D to exit the chroot and return to the FC9 VM. Now, you'll install the LSB Sample Implementation, and then finish the tutorial by building and running code in the Build Environment and Sample Implementation, respectively.

Download and Install the chroot LSB Sample Implementation

The Sample Implementation is distributed as a base tarball and an (optional) add-on tarball that has several test tools. (You can also download the Sample Implementation as a user-mode Linux binary, if you prefer that format.)

To begin the installation of the Sample Implementation, choose a location for the Sample Implementation within FC9. The /opt folder is a common choice. Next, create a temporary directory, and download and unpack the tarballs:

 1 $ mkdir /tmp/tgz; cd /tmp/tgz

 2 $ wget http://ftp.linuxfoundation.org/pub/lsb/impl/released-3.2.0/binary/ia32/l...

 3 $ wget http://ftp.linuxfoundation.org/pub/lsb/impl/released-3.2.0/binary/ia32/l...

 4 $ wget http://ftp.linuxfoundation.org/pub/lsb/impl/released-3.2.0/binary/ia32/l...

 5 $ wget http://ftp.linux-foundation.org/pub/lsb/impl/released-3.2.0/binary/ia32/...

 6 $ cd /opt
 7 $ tar xjvf /tmp/tgz/lsbsi-core-ia32-3.2.0.tar.bz2
 8 $ cd /opt/lsbsi-core-ia32
 9 $ tar xjvf /tmp/tgz/lsbsi-graphics-ia32-3.2.0.tar.bz2
10 $ tar xjvf /tmp/tgz/lsbsi-boot-ia32-3.2.0.tar.bz2
11 $ tar xjvf /tmp/tgz/lsbsi-test-ia32-3.2.0.tar.bz2

Command 1 creates a directory for the interim files. Commands 2-5 download the pieces of the LSB Sample Implementation:

Lsbsi-boot is a bootable system, including a kernel and other pieces of software to allow you to boot the Sample Implementation in stand-alone mode (if you want to).
Lsbsi-core is a basic run time that contains only those features spelled out in the LSB specification. You can use lsbsi-core to chroot and enter a virtual, LSB-compliant environment.
Lsbsi-graphics provides libraries to create graphical applications inside the Sample Implementation. As shown in [section2.html#fig1 Figure 1] at the start of this article, these libraries include functions for X and OpenGL drawing, among others.
Lsbsi-test adds additional software to make the Sample Implementation a suitable testing environment.

Commands 6-11 extract the tarballs into /opt, creating the directory /opt/lsbsi-ia32. Do not skip command 8; lsbsi-lsbsi-graphics-ia32-3.2.0.tar.bz2, lsbsi-boot-ia32-3.2.0.tar.bz2, and lsbsi-test-ia32-3.2.0.tar.bz2 must be extracted into /opt/lsbsi-core-ia32.

Like the Build Environment above, after you extract all the Sample Implementation, you can use chroot to get to it. Run the command chroot /opt/lsbsi-core-ia32 /bin/bash. To exit the chroot environment, press Ctrl+D at the new shell prompt.

Building and Executing Code in the Build Environment and the Sample Implementation

Build the simple code of Listing 1 within the Build Environment and run it within the Sample Implementation.

Copy files into the Build Environment

Within your FC9 VM, you now have three environments: the FC9 environment, the Build Environment, and the Sample Implementation. For convenience and clarity, create three working directories and set three environment variables to make copying files between them a snap:

$ FC9=/tmp/work
$ BE=/opt/lsb-buildenv-ia32/tmp/work
$ SI=/opt/lsb-core-ia32/tmp/work
$ mkdir $FC9 $BE $SI

The $FC9 directory is the working directory for downloading source code and keeping interim files as needed. For example, you can download the LSB-compliant binary created with the LSB Build Environment utilities to $FC9, and then copy them to the $SI directory to determine whether they run in LSB V3.2.0. (Everything should work perfectly.) the $BE directory is the directory for source code that you want to build with the chroot Build Environment. The $BE directory is available as /tmp/work after you run chroot /opt/lsbsi-buildenv-ia32 /bin/bash. Similarly, the $SI directory is the drop for binaries built in the Build Environment that you want to run in the Sample Implementation. The $SI directory is available as /tmp/work after you run chroot /opt/lsbsi-core-ia32 /bin/bash.

So, to build Listing 1 in the chroot Build Environment and test it in the chroot Sample Implementation, you download the code to the FC9 environment, and then run the following sequence (the prefixes in the command-line prompt were added for clarity):

(fc9) $ cd $FC9
(fc9) $ wget ftp://.../echoargs.c 
(fc9) $ cp echoargs.c $BE
(fc9) $ chroot /opt/lsbsi-buildenv-ia32 /bin/bash
(be)  $ cd /tmp/work 
(be)  $ cc -o echoargs echoargs.c
(be)  $ ./echoargs hello there
hello there
(be)  $ Control-D
(fc9) $ cp $BE/echoargs $SI
(fc9) $ chroot /opt/lsbsi-core-ia32 /bin/bash
(si)  $ cd /tmp/work
(si)  $ ./echoargs hello there
hello there
(si)  $ Control-D
(fc9) $ echo $FC9
/tmp/work

By the way, because FC9 is LSB V3.2.0-compliant, the binary you created in the Build Environment runs fine in FC9:

(fc9) $ cp $BE/echoargs $FC9
(fc9) $ cd $FC9
(fc9) $ ./echoargs this is cool
this is cool

Summary

While the example code shown in this tutorial was simple, the same techniques used to build and test a few lines of code apply equally well to a few thousand lines of code. Use the lsb-appchk tool to find questionable symbols. Try building your code with the LSB Build Environment utilities and within the stand-alone LSB Build Environment chroot environment. If you don't have an LSB V3.2.0-compliant version of Linux, use the LSB Sample Implementation to test the portability of your application. Leverage a tool such as VMWare Workstation to virtually (both metaphorically and practically) multiply your computing resources and run your targeted flavors of Linux.

With a little work, you can shape your application to be LSB compliant, and then apply to have your application certified. Certified distributions and certified applications allow users to invest in Linux comfortably. The LSB provides uniformity, which--perhaps paradoxically--promotes choice.

And after all, choice is what Linux is all about.

Attribution

This article originally appeared on IBM developerWorks. It has been revised to current technology practices. Thanks to Ted T'So and Jeff Liquia for updating it.

[906 reads | Printer-friendly version]