Executing Binary Files

Question

I downloaded a binary file that was compiled (a C program) using GCC 4.4.4 for x86-64 Red Hat Linux.

Is it normal that when I try to run it on a Mac OS X (running Lion so also x86-64) running GCC 4.2.1 that it would say: cannot execute binary file? It can't detect it as a binary file.

Why would it do that? I believe the gcc version has nothing to do with that since the file has already been compiled. It has been compiled for x86-64 of which both machines run. Can someone please explain?

Solution 1

It's highly unlikely that a binary compiled for a particular OS will run on another. Either get a binary for Mac, or get the source and compile it yourself.

There are many things that will cause issues - version of libc and libstdc++, there can be difference in versions of .so libraries - different API interface to the OS itself. Or even a different binary format (ie VMS binaries do not run on AIX).

Solution 2

There are different binary formats. Linux systems use ELF for executables and libraries, but Mac OS X uses the Mach-O format. Windows uses another still: PE format.

Solution 3

Although Rad Hat Linux and Mac OS X are both 'Unix based', they cannot run each other's binaries. Just like you can't run Windows binaries on Macs and vice versa.

Comments

[darksky]

But don't both run x86-64? In a sense, the compiler will compile both to x86 assembly (which is the same on both machines). So would that mean that the assembler would convert the assembly code to different binary files on each machine?

[darksky]

Don't both run x86-64? In a sense, the compiler will compile both to x86 assembly (which is the same on both machines). So would that mean that the assembler would convert the assembly code to different binary files on each machine?

[old_timer]

the assembler and the compiler have nothing to do with it is the system libraries for that platform that matter and linux and macos are different platforms in the same way that the rubber tire and metal wheel have to be made to fit different size vehicles, the same brand can be on the side of the tire and wheel, the same mechanic can install them that doesnt mean one tire fits all. if the operating systems were the same there wouldnt be a windows and linux and macos, etc.

[old_timer]

the assembler and compiler and linker from a pure sense only need to know that it is an x86-64. You make a hello world program with a printf for example. Even much of the C library is consistent and portable across platforms but the c library layer that your program sits on has an other side, the other side is where the C library interfaces with the operating system, and that is where things are different someone either on the C library side or on the operating system side or both has to customize it to make system calls for the particular operating system which is ultimately not portable.

[old_timer]

create something very simple, a printf is complicated but might be simple enough, maybe just a program with a single putchar or putc, compile it on both platforms linking in static not dynamic. disassemble both and compare.

[Adrian Cornish]

The compiled result for actual instructions could be the same, but say we have Nayefc OS - you may decide you want the executable laid out with all global variables first, then functions, then hardcoded text strings, now I who wrote Adrian OS I want the functions first, then a gap of 27680 bytes (because I like it) then .. - you get the point. So a windows EXE is different from a Linux exe and possible a Mac exe