Updated: November 22, 2012
The problem you are facing is this: Recently, you have upgraded your installation of Linux to a newer version. You have recycled your home directory, as it contains many useful programs and games. However, since the upgrade these programs no longer work. When you try to run then, you get the file not found error.
You may suspect you are facing permissions and file attributes problems, like the executable bit, but you can obviously see that it's not that. Something else is afoot, and you're not quite sure what to do. This short tutorial will teach you how to approach problems revolving around executable binaries and making them work again.
As mentioned earlier, you are facing a silly situation. Let's say you have a game, like Enemy Territory Quake Wars, which worked marvelously on Lucid, but now seems to stutter on Pangolin. And by stutter, I mean, it won't start at all. Yes, you did your homework, the file has the proper 755 permission, it's where it ought to be.
But for some reason, the shell throws the file not found error. And no, you're not having any BASH problems ethers, because other stuff and some custom script or even other programs and games work just fine. So what now?
You need to figure what's wrong. The best way to handle binary files is to figure out if there's anything wrong with these files. To that end, you will want to use the file command, which we mentioned in my Linux cool hacks tutorials, all four of them, links below.
If the command returns output that reads ELF something executable, you are ok. But then, read the whole thing. Is this a 32-bit or a 64-bit executable? Is it dynamically linked, that is, does it use shared libs?
This will give you the direction you need. If you're using 32-bit libs on 64-bit systems, this might be the problem you're facing. Moreover, if the binary uses shared libraries, then you will want to use the ldd command to check whether the binary is linked correctly.
All right, let's see what ldd reports:
not a dynamic executable
But that's not true. We know this is a dynamically linked executable. We know that it used to work just fine in previous versions of our operating system. And yes, please verify that you're not running ldd against a wrapper script, because it is not an executable.
So what now? The answer is: If the system reports an executable is not an executable, you are most likely missing the correct version of libraries, all of them, for your binary. Most importantly, you're missing the right version of GLIBC too. This usually happens when you try to run 32-bit programs on 64-bit systems.
Install 32-bit libc libraries
We do that - example shown on Linux Mint 13 Maya:
sudo apt-get install libc6:i386
Next, we check our binary again with ldd - voila:
As promised, some useful articles that will help you become more of a geek:
Linux debugging super tutorial
Linux useful commands & configurations
There you go, short, simple and handy. This guide teaches you not only how to overcome a small nuisance resulting from an upgrade, but it also highlights the way of thinking and isolating your problems. We used a small number of commands, like file and ldd, and yet we gained an abundance of information that helped narrow down the issue and come with a quick solution.
You get a bit of everything here, system upgrade woes, figuring out permissions, checking file type, architecture and linking, correlating to ldd output before and after the upgrade, installing several libraries, and doing all of that from the command line. Plus you get a wealth of tips and tricks listed in six other tutorials, all of which should help you master your Linux box and gain additional confidence in resolving system issues. That would be all.