Problem solve Get help with specific problems with your technologies, process and projects.

Porting Solaris applications to Linux, part 3

Ken Milberg outlines the differences between Solaris and Linux that you'll need to keep in mind to compile your apps successfully.

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.

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:

graph list sec ws

GCC Sparc cc Description
-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:

graph list sec ws

GNU Solaris Description
-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, 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, and I'll respond quickly.

Dig Deeper on Linux servers

Running Linux on the bare metal, part 2 In your response to the person who asked you about running LINUX bare on a mainframe, it seemed to be that you politely understated the case. I know very little about Linux, but I thought running "bare" also included having to code all of your own interrupt handlers, IO drivers, etc. This alone would require almost as much effort as developing an operating system. Am I really off base here? Does Linux handle all of that stuff?

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.