Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .