Can I run a binary compiled from higher version of gcc?

Question

For example, my local machine only has gcc 4.4. Can I run a binary compiled from gcc 4.8?

Answer 1

Running a binary is dependent on your libraries, not your compiler, so it doesn't matter which gcc is installed. Check your library versions.

Answer 2

There are several possible answers here, depending on the particular circumstances:

First, an important factor whether the binary in question is C or C++. The C++ ABI is tightly coupled to the compiler. It's highly unlikely that you will be able to run C++ code built by a higher version of gcc. The C++ standard library comes with the compiler. If you do not have gcc 4.8 installed, you won't have that version's libstdc++ installed either, and it's unlikely that any gcc 4.8 C++ code will run. Generally, it's far more likely that libstdc++ will have forward, than backward, compatibility.

The C ABI, rather, is less tightly married to the compiler, and there is a moderate chance that pure C code will run, as long as it doesn't use any symbols from the C standard library that are specific to a higher version of libc. Same goes for every other shared library used by the particular code in question.

But there is also one other answer:

Simply "no", that's it. This question is often asked in the context of having an established seat of an older version of a commercial Linux distribution which ships with a stale version of some popular package, often Apache, or it could also be Mysql, perhaps PHP or something similar; and there is a requirement to install another product that requires a newer version of the component, that's available in the current version of the commercial Linux distribution, but not in the older version being used.

So this kind of question is an attempt to figure out whether it's possible to simply grab Apache, or whatnot, from the current version of the distro, and somehow cram it inside the older version. When I hear the question being asked here, it's been my experience that this kind of a question is really a manifestation of this class of an XY problem.

And the proper answer is to either update your commercial Linux distro to the current version, or grab the source code to the newer version of the software package in question, and build it using your commercial Linux distro's packaging tool, then proceed to execute a standard update of this system component using the commercial Linux distro's regular package update process; rather than attempting to execute this kind of a half-hearted transplant from a newer version of the Linux distro, due to lack of local developer and/or sysadmin resource which has the necessary knowledge to prepare a proper software update build. This kind of a brain transplant rarely works, at best it results in random instability and crashes, and becomes a perpetual drain of support resources.

The answer here needs to be the right answer: either update your Linux distro properly, or build the newer version of the software in question from source, using the system compiler.