Once the decision is made to build a new application that is LSB compliant, what needs to be done next? There is some setup involved to develop an application to the LSB. The steps involved in setting up are:

• Download and Install the LSB Software Development Kit (SDK)
   
• Install the LSB SDK
   
• Download and Install the Linux Application Checker
   
• Download and Install the LSB Sample Implementation

After you have begun to develop your application, there are good strategies to undertake to achieve LSB compliance, using the Linux Application Checker tool. Those strategies are also provided in this page.

Download the LSB SDK

The LSB SDK contains the development environment for building LSB certifiable applications. It is in the form of a tarball and contains an install script. The download for the architecture needed can be found here on the LSB site. Download and save the file.

Install the LSB SDK

After downloading the LSB SDK package (tar.gz) for the desired architecture, follow these steps to install the SDK.

1. Unpack the package:
   

   tar xzf lsb-sdk-<version>.<architectue>.tar.gz
   

   for example tar xzf lsb-sdk-3.2.0-4.ia64.tar.gz




2. Go to the subdirectory lsb-sdk created when unpacking the tarball.
    
3. Run the install script ./install.sh Note: Root privileges may be required.

After installation, it's a good practice to add /opt/lsb/bin to the PATH environment variable. This will allow the developer to only have to enter lsbcc to compile and link the application.

Another variable that can be changed is MANPATH. There are manpages associated with the LSB. By updating MANPATH they can be accessed. Add the following to the MANPATH: /opt/lsb/man.

The following is actual output from installing the ia64 LSB SDK.

cal@bilbo:~/lsb-sdk> ./install.sh

This system appears to be a RPM-based distribution, such as those from Red Hat, SuSE/Novell, Mandriva, Asianux, etc.
Is this correct? yes
In order to install these packages, you need administrator privileges. You are currently running this script as an unprivileged user.
You have sudo available. Should I use it? yes
Using the command "sudo /bin/sh -c" to gain root access. Please type the appropriate password if prompted.

Installing packages...
root's password:
There may have been problems with the package installation. Check error-log.txt for more information

cal@bilbo:~/lsb-sdk>more error-log.txt
warning: lsb-build-base-3.2.1-1.ia64.rpm: Header V3 DSA signature: NOKEY, key ID a0530ad1

cal@bilbo:~/lsb-sdk>

The error flagged was just a warning and can safely be ignored.

Download and Install the Linux Application Checker

The instructions for downloading and installing the Linux Application Checker are available on the Linux Application Checker Getting Started page.

Download and Install the LSB Sample Implementation

For more information on using the LSB Sample Implementation, see the LSB Sample Implementation page.

LSB-Compliance Strategies

Now that you have obtained the LSB build and test tools, you can being the development process of your application. As you complete the build process, you can test the application with the Linux Application Checker and discover how far along your are on the path to LSB compliance. In particular, you can visit the LSB Certification page of the Test Report to see which libraries and interfaces your application is using that are preventing LSB compliance. Once identified, there are four recommended strategies for developers to take to work towards LSB compliance. It should be noted that these strategies are good for developers who are targeting specific distributions for portability, not just for LSB certification.

Remove the non-LSB dependencies with these strategies in mind:

• Using alternate interfaces (i.e., posix_memalign() instead of memalign())
   
• Using alternate libraries (i.e., libnss instead of openssl)

Note: This is a good idea regardless of whether an ISV is pursuing a path towards an LSB-compliant application or just explicitly targeting cross-distro portability, as openssl has different ABI's across different distributions and different distribution versions)

• Statically link libraries

Caution: Care should be taken when statically linking libraries as some software licenses, such as the GPL, treat statically linked libraries are part of the main application body, and thus extend the license conditions to the main application.

• Dynamically link with shared libraries shipped by the ISV

These are strategies that will definitely be expanded upon in the near future on LDN, as each one contains its own best practices.