How to Build LSB Applications

Don't leave your Linux software stuck on one distribution. Make it run anywhere with the standard that all the major distributions use.

The tools described here take care of this process for you.

The LSB Build Environment

A long time ago, people realized that code changes are cheaper and easier to make when they come earlier in a development process rather than later. With this in mind, the LSB Project has created a build environment to assist with the creation of LSB-conforming applications. This build environment provides a set of clean headers, stub libraries and a compiler wrapper.

The LSB stores much of its definition in a database. In addition to the portions of the specification that would be tedious to edit manually, we are able to produce a set of clean header files and stub libraries that contain only the things specified by the LSB. Using the database in this way helps to ensure the tools and specification stay in sync as changes and additions are made. The packages you need to install are described in the “Linux Standard Base Packages” sidebar.

The first step in building an LSB-conforming application is to compile the code with the LSB headers. If the code doesn't compile, it probably is using something outside of the LSB. This isn't necessarily a showstopper, but it is something to which you need to pay particular attention. The LSB headers are installed in /opt/lsbdev-base/include. As a quick test, pass -I/opt/lsbdev-base/include to GCC and see what happens. The compiler wrapper described later does this step and some other related steps for you.

Once you have compiled your code, the next step and next test is to link the code together to form the final application. Usually, this step looks like this:

gcc -o app1 obj1.o obj2.o -lfoo

The LSB stub libraries can be found in /opt/lsbdev-base/lib and can be specified by passing the -L option to the compiler. These stub libraries are used only at link time. Typically, the normal system libraries are used at runtime. Again, the compiler wrapper described later handles these details for you.

Once you have linked your application, use the ldd command to see what shared libraries are being used. At this point, there should not be any shared libraries other than the ones specified in the LSB (and listed in the “Linux Standard Base Libraries” sidebar). If there are, you need to take extra steps to make them be linked statically. Usually, the -Wl,-Bstatic and -Wl,-Bdynamic options can be used to specify that certain libraries should be linked statically. By now, you may be seeing a pattern: the compiler wrapper handles this for you.

As an example, here is what the application xpdf typically looks like:

# ldd /usr/bin/xpdf => /usr/X11R6/lib/ => /usr/lib/ => /usr/lib/ => /usr/X11R6/lib/ => /usr/X11R6/lib/ => /usr/X11R6/lib/ => /usr/lib/ =>
         /usr/lib/ => /lib/ => /lib/
  /lib/ => /lib/

Here is the LSB-conforming xpdf:

# ldd /opt/lsb-xpdf/bin/xpdf => /usr/X11R6/lib/ => /usr/X11R6/lib/ => /usr/X11R6/lib/ => /lib/ => /lib/ => /lib/
    /lib/ => /lib/

The non-LSB libraries are not showing up as needed by the application, because they are linked statically into the application itself. There is a trade-off here: the application executable becomes larger, but it has fewer dependencies on the installed operating system.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState