Despite some skeptics' opinions, Linux really is different from Unix, and people who use Linux know that that difference is a good thing. Just the cost savings alone will make it worthwhile to port your Solaris applications to Linux, and cost reduction is just the tip of the iceberg. In this three-part series on Solaris-to-Linux porting, I've offered tips on laying the groundwork and working with compilers. Now, let's look at compiling successfully. To do that, you'll have to understand the differences between Solaris and Linux.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Let's start with compilers and finish with linkers. More than likely, you will be using either CC or GCC. Both the CC compiler and GNU compiler have extended the C language. Since the direction of the port is Sun to Linux, this is not a major issue. The options to select the various modes are very different. If you are going with the method of compiling your gcc code on the SPARC server, then you'll need to download the appropriate GNU tools and install them on your Sun box. Then, start building the app using gmake instead of make. After you have modified the makefiles to work with gmake, you'll need to change the name of your compiler to GCC from C and G++ from C++. At that point, you can start rebuilding your applications.
The options to tell the compiler to compile but not link (-c), specify the output file (-o), adding a search library directory (-lname), define preprocessor macro (-Uname), telling the compiler to leave out debugging (-g), compile but don't assemble (-S) and the option to stop printer warnings (-w) are the same on both compilers.
Unfortunately, there is an abundance of differences between both the compilers. Here are just some of them:
|-static||-Bstatic||Has the compiler statically link the application|
|-O||-fast||Enables options to maximize speed of compiled app|
|-shared||-G||The linker creates a shared object with this flag|
|-flags||-- help -v||Prints summary of options|
|-save-temps||-keeptmp||Instructs compiler not to remove temp files|
|-M||-H||Prints the path name of each file being compiled|
Another piece of software, which is also critical, is the linker. The linker controls the final form of the actual code and is critical that you use it correctly. Again, SPARC and the GNU version have some similarities on both platforms but also tons of differences. It is important to familiarize yourself with these differences. Go on-line to GNU and familiarize yourself with the documentation for the GNU linker to help you compare the two. Here's a table with some of the differences:
|-shared||-G||Generates a shared object|
|-static||-a||Enables default behavior in static mode and prevents linking with shared libraries|
|-Ldir||-L directory||Adds directory to list of directories|
|-rpath path||-R path||Specifies search direction to run-time linker|
There is a ton of information on-line that will help you understand the GNU tools better. Do not hesitate to do the research and spend the time understanding the new tools that you will be using. Start with GNU.org, but don't stop there.
One final note: It's important to understand that apps that are designed for SPARC servers use non-standard functions that can hinder a port to Linux. A provisional STL is supported on Intel's Linux that can help ease the pain of porting those apps. It provides the Solaris API threads that are layered on the POSIX thread library. STL is a component of Solaris Compatibility Libraries and is available in open source, though SourceForge.
In my next article on porting applications from Solaris to Linux, I'll cover training needs for shops moving from Unix to Linux. In the meantime, I'd like to get your input. Do you have questions about this topic? Would you like more information about compilers? Would you like more information about a certain porting task? Do you disagree with any of the advice I've offered in this series? If so, please write to me c/o email@example.com, and I'll respond quickly.