Binaries

[yanom]

If I write a C++ code and compile it to a Linux binary, will that binary run on any Linux computer, regardless of distribution or the processor type of the computer? (providing that the computer has appropriate RAM, video card, processor power, etc. for the program)

[nalg0rath]

Short answer: No, it wont run on any system.

This is because system libraries are (often) different on teh Linuxes. So even if the architectures are the same the portability of Linux binaries is not so good. If you use binaries they should be specific to a version of a distribution (as a general rule).

(Using static libraries will eliminate this problem)

You cannot run binaries for different processortypes if your processor type does not have backwards compability so that it supports the instructions of the architecture the binary was compiled for. In practice it does not even work when you have backwards compability unless the programmer is very careful to make the program portable. You wont be able to run a amd64-, sparc64-compiled binary on a i386 machine.

Another edit:
Some architectures support the emulation of other architectures even if the instruction sets are not compatible but emulation isn't a very good option unless it is the only option.

[i92guboj]

Short answer: No, it wont run on any system.

True. The architecture is determinant and so it is the compatibility at ABI level. For example, if you compile anything against glibc-2.4, more tan probably, it will not run on a system with glibc-2.8. Some times, as you very well said, this can be overcome to a certain extent by compiling the libs statically on the same binary file. This eliminates the need to link against external libraries.

You cannot run binaries for different processortypes if your processor type does not have backwards compability so that it supports the instructions of the architecture the binary was compiled for. In practice it does not even work when you have backwards compability unless the programmer is very careful to make the program portable. You wont be able to run a amd64-, sparc64-compiled binary on a i386 machine.

Yep. This is why linux distributions offer many binary copies of the same package, one for x86_64, one for x86, one for sparc, arm... and so on. Each cpu type needs a binary that is compatible with that cpu.

Another edit:
Some architectures support the emulation of other architectures even if the instruction sets are not compatible but emulation isn't a very good option unless it is the only option.

It depends. If you had x86 vs. amd64 in mind, note that in this case it's not emulation. Amd64 can run x86 object code natively, you just need to take care to make available all the needed libs. For example, you can run a 32 bits opera browser on gentoo for amd64, but portage will then install the basic 32 bits libs (which are available on gentoo via its package manager) because a 32 bits opera binary can't link against the 64 bits versions that are already installed on the system.

In terms of portability of binary objects, the best you can do is to compile for 32 bits, and link statically when possible. This way, you will ensure that your binary file will run into x86 and x86_64 at least. Make sure you don't enable exotic features like -msse3 and the like, or your binaries will fail to run on any cpu that has not that extension.

[nalg0rath]

It depends. If you had x86 vs. amd64 in mind, note that in this case it's not emulation. Amd64 can run x86 object code natively, you just need to take care to make available all the needed libs. For example, you can run a 32 bits opera browser on gentoo for amd64, but portage will then install the basic 32 bits libs (which are available on gentoo via its package manager) because a 32 bits opera binary can't link against the 64 bits versions that are already installed on the system.

Since amd64 contains all instructions of the 8086 instruction set (technically the set of all amd64 machines is a subset of the set of all x86 machines) there is ofcourse no need for emulation of x86 on amd64. I had in mind more odd architectures like ARM, MIPS, PPC for the emulation alternative.

[yanom]

if i make my code platform-independant (using wxWidgets), will it work then?

[techieMoe]

if i make my code platform-independant (using wxWidgets), will it work then?

That depends on what you mean by "platform-independent". You seem to mean processor-independent, and in that case C++ cannot be completely platform-independent because it is compiled for a specific processor architecture.

If you mean it will work on pretty much any Linux distribution on the same computer or several computers with similar hardware (at least the same processor) then yes.

The only way to make software completely platform-independent (meaning processor, OS, desktop environment) is to write it in a language that isn't compiled, but rather interpreted like Java.

[i92guboj]

That depends on what you mean by "platform-independent". You seem to mean processor-independent, and in that case C++ cannot be completely platform-independent because it is compiled for a specific processor architecture.

Yes. This is something that the original poster does not understand well, I think.

When we say that C++ or a given toolkit like wxWidgets or gtk+ is portable, we mean that the code can be compiled with very little extra effort on a given number of OSes and/or architectures. But essentially, linux and windows are different OSes, and they are incompatible at binary level. A binary for windows will not work in linux, or vice-versa. It doesn't matter which language you choose, or what toolkit you use. It it was that easy, then things like wine would make no sense.

If you want a program to be portable out of the box, without recompiling, you have two options: scripting language, or byte-code based ones: java, python, etc. As techieMoe already said. Those language are interpreted just-in-time, while the program is ran, this is why they can be run on any OS which has an interpreter.

So, as long as you use compiled code, you are tied to the OS and the cpu it was compiled for.

I hope this helps a bit.