Porting your application to multiple distributions is a task that conjures up images of large engineering and support costs, which detract from the real value of the Linux platform. It is the primary goal of the LDN to provide the skills and the tools to vastly reduce those costs by emphasizing portability techniques for cross-distro application development, or full LSB certification.

One of the best ways of enhancing portability is to use the LSB Application Checker to test your application and see 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 prevent LSB compliance. Once these components are identified, there are four recommended strategies for developers to take to work towards LSB compliance. Even if such compliance is not your goal, the very process of moving towards the LSB ensures you will have a much more portable application when all is said and done.

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 if you are 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

There are, of course, other more general strategies to use when porting your application:

• Consider endianess (big versus little) This is typically done at the architecture level
  

• Consider 32-bit versus 64-bit. Do not use anything that relies on one or the other
  

• Avoid hard-coded addresses
  

• Use sizeof when getting sizes of objects. This is especially true when going from 32-bit to 64-bit
  
  
• Do not assume that char is signed or unsigned
  
  
• Do not assume that float is the same size as double<br /><br type=“_moz” />
• Be very careful when using #ifdef<br /><br type=“_moz” />
• Always create function prototypes and have the compiler check for strict use by using the -Wstrict-prototypes option in compiling
  

• Use POSIX interfaces and data types
  

• Use only standard functions that are in the C and C++ libraries
  

• Avoid extensions to libraries or libraries that are distribution-specific
  

• Use the LSB tools found in the LSB SDK for building applications
  

• Follow the FHS for file system hierarchy