-bash: ./flume: No such file or directory BUT flume is there and works elsewhere

We have a product built on CentOS 4 32-bit Linux that runs unmodified on 32- and 64-bit CentOS/RHEL 4 and 5 and SLES 10. It also runs unmodified on SLES 9 64-bit. [SLES 9 32-bit requires a different libstdc++.

The name of the main binary executable is flume

Yesterday we tried to put this on 64-bit Ubuntu 10 and, even though the file is there and the right size, we get:

-bash: ./flume: No such file or directory

file flume shows it to be a 32-bit ELF (can't remember the exact output and the system is on an isolated network)

If put into /usr/local/bin, then:

which flume
/usr/local/bin/flume

I did not try ldd flume yet.

I now suspect that some library is not there.

This is a profoundly unhelpful message and one I have never seen before.

Is this peculiar to Ubuntu or perhaps just to this installation.

We gave up and moved to a RHEL 4 system and everything is fine. But I sure would like to know what causes this.

You can get this message if flume exists but its “loader” doesn't exist, where

• the loader of a native executable is its dynamic loader, for example /lib/ld-linux.so.2;
• the loader of a script is the program mentioned on its shebang line, e.g., /bin/sh if the script begins with #!/bin/sh.

In your case, it looks like you don't have the 32-bit dynamic loader installed on the 64-bit Ubuntu system. It's in the libc6-i386 package.

strings ./flume | head -n 1 will display the path to the dynamic loader that flume requires. This is one of those rare cases where strace ./flume is completely unhelpful.

I consider this situation to be Unix's most misleading error message. Unfortunately fixing it would be hard: the kernel can only report a numeric error code to the caller of the program, so it only has room for “command not found” and not for the name of the loader it's looking for.