Writing compatible code for Linux

Four · 04-30-2008, 06:02 PM

Hi,

What I want to do essentially is not release all code to the general public. Also make binaries which will run on various Linux Boxes. I'm clueless of what to search on google for this. I tried but didn't get anywhere.

I compiled the following code on PC1

Code:

#include <stdio.h>

int main(){
    printf("hello world");
    return 0;
}

Code:

PC1> uname -a
Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 i386 GNU/Linux

Works fine on PC1
Now taking the executable only compiled with PC1 onto PC2

Code:

PC2> uname -a 
Linux someaddress.something #1 SMP Wed Feb 27 04:48:20 EST 2008 i686 i686 i386 GNU/Linux

PC2>./helloworld
Floating point exception

Floating point exception?

Where may I look for more info? What kinds of things can I do to the hello world to run on more Linux boxes? Opinions?

Thank you

Edit: After reading my own title I searched "Linux compatible binaries". I feel this is a redundant thread now. Atleast asking a question gave me an idea of a query to google.

chrism01 · 04-30-2008, 07:11 PM

The key word here is 'portability'; you should find plenty of hits on google for writing portable code.

jlliagre · 04-30-2008, 09:29 PM

Source code portability doesn't imply binary portability/compatibility from one version to another. This cannot be guaranteed with most OSes including Linux.

Scripting and VM based languages like Java provide a better independence from the OS.

Denes · 05-01-2008, 12:59 PM

This is interesting to me too. From what I have seen it is usually okay to run a binary compiled with older libraries with newer ones but not the other way around. This is not always true though. The company I used to work for had a version of slickedit that ran up until RH8 and then bombed out on RH9. The Win32 version did not suffer from that problem. I still am a little sore about that.

Even more interesting to me is how a company such as NVidia does it at the module/driver layer which complains on version incompatibility?

Four · 05-02-2008, 11:27 PM

Another solution I found interesting, If you redistributing on CD you could have like one big ar file or tar file. Unfortunately the user will need to have some mandatory tools like tar, gcc, g++, ar, sh, zenity.

Step 1: Compile only to the point before linking. You should have a bunch of object files.
Step 2: Write an bash script that will link everything together and install
Step 3: Redistribute only the object files and bash script

From the end users perspective.

Step 1: run bash script, a progress bar appears (using zenity)
Step 2: Click Next, Specify parameters (if needed) next, next
Step 3: Run installed app

Problem: Dependency pain.

To ease dependency pain: Have shell script detect if it will happen and give the user a check list of all dependencies needed.

Perhaps there is a way to reach a solution where the end user can just run the binary of a read only CD.

jf.argentino · 05-03-2008, 10:28 AM

Generaly, the biggest problem to face with binary portability are:

-the libraries versions mismatch, program need functionalities which aren't available in a specific library, and interfaces can change.

-the difference between gcc versions used to compile the program and the libraries it uses.

I think that you face the second one, check your gcc version you use in PC1, if it's newest, get an oldest one (generally, repositories still have ggc34), otherwise, get the latest gcc release.

Valery Reznic · 05-04-2008, 10:32 AM

Quote:

Originally Posted by jf.argentino

Generaly, the biggest problem to face with binary portability are:

-the libraries versions mismatch, program need functionalities which aren't available in a specific library, and interfaces can change.

-the difference between gcc versions used to compile the program and the libraries it uses.

I think that you face the second one, check your gcc version you use in PC1, if it's newest, get an oldest one (generally, repositories still have ggc34), otherwise, get the latest gcc release.

You can try to solve binary portability problem (or at least considerably increase supported Linux version) using

Ermine (http://magicermine.com) or statifier (http://statifier.sf.net)

Valery