There are many ways to handle porting from Solaris to Linux, and I have tried many of them and now have two favorites. I'll share these two methods in this installment of my three-part series on porting from Solaris-to-Linux. But if you haven't done the analysis described in part one, moving ahead to porting methods is putting the cart before the horse.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In fact, before we drive on into the details of the porting methods, let's make sure you've answered these basic questions:
- What application packages do you currently run on Solaris that will need to run on Linux?
- Do you use middleware? If so, what is the satisfaction rate of the product on Linux? For example, if your product is IBM WebSphere, do some homework to see if other customers are happy with their migration to Linux. At the same time, ask them about the problems they encountered.
- Are there any specific development tools that will need to run on Linux? Are they available?
- What hardware dependencies will need to be supported with Linux? For example, is there tight integration in your code with Sun's SPARC processor?
- Are there issues with the network that will need to be addressed?
- What will you do about your direct access storage devices (DASD)? How are you currently storing data, and will that change?
- Are there any hooks to the Solaris kernel in your code?
- With Solaris you can assign processes to a particular processor. Is this being done on your current box?
I don't like to beat a dead horse, but I'll say it again. Spend the proper time during the assessment. You won't regret it later!
Two ways to port
Regarding the different ways to port, let's look at two basic methods: working with GNU compilers on Solaris; and copying the code to Linux and compiling there.
The first method is using the GNU compilers on Solaris, and -- in my opinion -- compiling the code on Solaris and your SPARC server will make the port that much easier. If the application can be recompiled and regenerated on Solaris using the GNU tools, it can later be moved over to Linux. This is a safer bet, for one reason, because you won't run into any language issues and will run into API issues only. Keep in mind that Linux is actually supported on Sun today, which makes the whole concept of testing your SPARC-compiled Linux code possible.
Sun gives you a suite of freeware that provides all the tools you need to do what you want. This information will help. Also, Sun actually provides for a common library to help your process of developing the code that is compatible across your environments. The tools will help you with things like translating your custom shell scripts and identifying any library call differences in your C code.
The other option you have of course is to copy the code to Linux and compile it there. The key to a successful port with this plan is testing. You must be very thorough in ensuring that your recompile is complete. You may run into issues where code is just not running the way you thought it might after doing a recompile, and this might happen because of a bug in an original software update on the source. Also check to ensure that the modified code is endian neutral.
Before moving the code over, start looking at the source code for potential problems. Some things that you will need to look for in your source are: macros for printf routines, #else statements and system header files. You'll also need to check for problems with things like library compatibility, variables, and functions and flow control. This process includes copying the source tree and makefiles to the Linux box and rebuilding your application.
You will definitely need to modify your application to allow for differences in the run-time APIs for the different platforms. Look out for SPAR code that may hinder your ability to sleep. You'll need to modify that code for the port to work.
Don't forget to look at porting tools that will help you identify any problems along the way. One such tool is the Linux Compatibility Assurance Toolkit 1.1 (LinCAT), which is used to identify porting issues in C/C++ source code files. It analyzes the differences between the source files from Linux to Solaris and can really help estimate the required to do a successful port. Check it out here. You can find more information on Sun's Linux pages.
Whatever option you pick, be prepared to test, test and test some more. Testing is definitely the key to success in a port. I'll discuss testing in depth during the next part in this series.