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:
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.
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.
After downloading the LSB SDK package (tar.gz) for the desired architecture, follow these steps to install the SDK.
tar xzf lsb-sdk-//<version>//.//<architectue>//.tar.gz
for example ''tar xzf lsb-sdk-3.2.0-4.ia64.tar.gz<br /><br type="_moz" />'' - Go to the subdirectory lsb-sdk created when unpacking the tarball.\\ - 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.
The instructions for downloading and installing the Linux Application Checker are available on the Linux Application Checker Getting Started page.
For more information on using the LSB Sample Implementation, see the LSB Sample Implementation page.
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:
posix_memalign()
instead of memalign()
)
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)
> 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.
These are strategies that will definitely be expanded upon in the near future on LDN, as each one contains its own best practices.