Question: 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.

Answer: 
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.
Did you try to give execute rights to the file? 

```
chmod +x ./flume 

```