32-bit applications on SLES 12? Yes!

SUSE’s ISV team has received several questions from partners in the past few months about whether they can deliver and support their 32-bit applications on SLES 12. Our response to them is “Yes, you can!” The process may be a little unexpected, but it works. Our long-standing partner, Scalix, a provider of innovative email and collaboration solutions, is doing it.

If you focused your SUSE Linux Enterprise 12 attention on SP1, you might have missed the following in the SLE 12 release notes.

4.2.1 Running 32-Bit Applications
SUSE does not support 32-bit development on SLE 12. 32-bit runtime environments are available with SLE 12. If there is a need to develop 32-bit applications to run in the SLE 12 32-bit runtime environment then use the SLE 11 32-bit development tools to create these applications.

Scalix wanted to help their SLES 10 customers update their email platform from that environment to SLES 12. Our ISV team worked with them to line up just what they needed to move up to SLES 12 for current customer upgrades and for expansion in their current window of opportunity.

The first step was to compile in the current SLES 11 environment. Scalix developers were very precise in sending information to our ISV team so that we could assist them as needed in the process. Their precision made it easy for our ISV team to work with development to identify exactly what they needed and where to find it. Build and test were successful.

The next step moving to SLES 12 was straightforward. Between SLES 11 and SLES 12, there was a version upgrade to one library Scalix needed to link to. To check the function compatibility, we explored making a symlink so that the …so.3 version (the current SLES 12 library) linked to the …so.2 version (the SLES 11 library) which they loaded onto the SLES 12 system. Scalix testing was successful with the link. However, we all had a concern about whether adding a permanent symlink as part of their installation might have effects on other applications running on the SLE 12 system. We also briefly considered whether it was an option for Scalix to ship an additional …so.2 library version with their application – that is what open source is all about – but we all wanted to ensure that their customers received all software updates as soon as possible with SUSE support on their base system.

With the modular structure of SLES 12, we had another option for Scalix – the legacy module.

If you haven’t had a chance to look at modules, there is a good overview white paper available. The legacy module for SLES 12 is designed to provide older packages for applications that rely on function not in the SLES 12 base. These are generally used by applications moving to SLES 12 from earlier releases or from UNIX systems.

Having Scalix use the …so.2 version of the library from the SLES 12 legacy module while maintaining the …so.3 version as part of SLES 12 base, was a great solution for them.

• Scalix has the precise library interfaces they need to work with.
• They don’t require any additions to their SLES 12 product shipment to support their product on different SLES versions.
• Their customers can just check the box to install the legacy module as they install SLES 12. This is easy for Scalix to document and gives their customers assurance that they are using standard SLES function that is supported by SUSE.

So, for 32-bit applications delivered on SLES 12, “compile on version 11, run on version 12” is a great solution for SUSE and our partners for x86 and z System. We would note that SLES for Power systems with the change from big endian in SLES 11 to little endian in SLES 12, is ready in SLES 12 for 64-bit applications where that build environment is fully available. For ISVs currently providing 32-bit applications, having their customers run the 32-bit application on SLES 11 in a virtual image is a good option for their customers running SLES 12 on Power 8 as their base system.

Yes, you can run and support 32-bit applications on SLES 12.