Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is already posted in serverfault - and may be more apprpriate there. Reworked a bit from the orginal posting.

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' returns: /usr/local/bin/flume

The file is marked as executable (did 'chmod +x flume') and lsattr shows no problems with attribute bits.

I was not able to try 'ldd flume' yet. I have also not tried 'strace flume'. Currently I am with an air conditioning failure. [It's been that kind of week!]

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.

share|improve this question
See the thread at serverfault. – Gilles Jul 18 '10 at 14:58
The serverfault thread is enlightening. – lcbrevard Jan 28 '11 at 1:25
up vote 3 down vote accepted

[copied from Gilles' answer on Server Fault]

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/;
  • 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.

share|improve this answer

I have had something similar, in the end it was due to the fact that libstdc++5 has been removed from ubuntu 10.04 and 9.10. I don't know why the error I got wasn't cannot find libstdc++, but when I installed it (from debian unstable) the error went away.

share|improve this answer

I had a similar problem with EXEs on Ubuntu 12.04 64-bit.

The solution for me was to install LSB on the target system:

sudo apt-get install lsb

The programs not working suddenly now worked. The bit on using

strings EXE-NOT-WORKING | head -1

provided the key. The LSB loader identified in the EXE-NOT-WORKING was a rev higher than the default ones showing up for other EXE files that were working.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.