Bash "can't find" binary executables

[EQvan]

Hi...

I am working on a custom hand-held device which runs a variant of Ubuntu Linux, 2.6.18. I have a set of 4 binary files (for oprofile) which have been known to run in this environment, but when I install them to /usr/bin, I can't run them: I get this message;

Code: Select all

root@ldogberry:/usr/bin# ./ophelp
-sh: ./ophelp: not found

This happens when I specify the full path, when I run from the /usr/bin directory -- it happens no matter what. Bash even does command-line completion on the file -- and then turns around and instantly claims the file is not found.

I've checked all of the permissions on the files -- they appear to the the same as the other files in the /usr/bin directory, which work correctly:

Code: Select all

root@dogberry:/usr/bin# ls -al opreport ophelp oprofiled objdump
-rwxr-xr-x 1 root root 550216 Sep 10 2008 objdump
-rwxr-xr-x 1 root root 27008 Jan 1 06:42 ophelp
-rwxr-xr-x 1 root root 591308 Jan 1 06:30 opreport
-rwxr-xr-x 1 root root 278321 Jan 1 06:30 oprofiled

Does anyone have any idea what might be causing this problem?

[DeletedAccount]

Hi,
The reason is that you might have just copied the binaries from somewhere with out thinking about any dependencies . ( Linux ain't windows ) try ldd <binary name > and see that all the dependencies are installed properly , it might possibly work after installing all the dependencies .

Regards
Shrek

[EQvan]

Hi... thanks for the suggestion. Unfortunately, the handheld device has a very limited subset of the usual commands, and ldd isn't on the list.

As it happens, I'm very familiar with this set of binary images, however; I know all of the dependencies, and I'm very confident that they are all in place.

Also, after seeing your suggestion, I did some experiments, renaming various libraries and running executables which depend on them... in such cases I get a reasonable message telling me which shared library is missing, not a message telling me that the executable can't be found.

[DeletedAccount]

Hi,
does the distro come with a package manager ? Then try installing it user the distro's package manager than manually copying it . These kinds out error usually happen when you manually copy the binary .

Regards
Shrek

[EQvan]

Alas, this is the embedded world, where everything is trimmed and reduced to the barest minimums. There is no package manager. Although our distro is based on Ubuntu, it's a pretty sparse variant...

In this environment it's very normal for me to copy a binary into place... and it's very *un*-normal for me to see the results I'm seeing.

The binaries that I'm trying to use are binaries that I generated about 6 months ago, and which worked then, on target platforms running the same version of the kernel, using the same root filesystem. Why bash is suddenly rejecting them, I can't understand.

I say "bash" is rejecting them, because that's how it appears: immediately, as soon as I attempt to execute the image, I get back an error message.

OH --- and it's not bash! I forgot, this is another thing that's been trimmed -- this platform runs "ash", which is generally similar to bash, but smaller, and with a few features missing (arrays, for example).

[JamesM]

Alas, this is the embedded world, where everything is trimmed and reduced to the barest minimums. There is no package manager. Although our distro is based on Ubuntu, it's a pretty sparse variant...

In this environment it's very normal for me to copy a binary into place... and it's very *un*-normal for me to see the results I'm seeing.

The binaries that I'm trying to use are binaries that I generated about 6 months ago, and which worked then, on target platforms running the same version of the kernel, using the same root filesystem. Why bash is suddenly rejecting them, I can't understand.

I say "bash" is rejecting them, because that's how it appears: immediately, as soon as I attempt to execute the image, I get back an error message.

OH --- and it's not bash! I forgot, this is another thing that's been trimmed -- this platform runs "ash", which is generally similar to bash, but smaller, and with a few features missing (arrays, for example).

Hi,

I suggest you strace it and see where the problem lies by the error messages returned by the kernel.

Code: Select all

strace ./myprog

[EQvan]

strace is another of the luxuries my handheld target doesn't afford, but this is such a good idea I think I'll go look into what it would take to get strace running on the target platform. It may be as simple as cross-compiling the executable... I see ptrace symbols in the kernel, so that support is probably already there. Thanks!

[Craze Frog]

Let me guess: unix sucks again? You see, since there is no native support for directory monitoring and querying the filesystem all the time slows things down, the shell developers decided to add directory hashing of the $PATH. Essentially this means that bash keeps a hash table of executable locations instead of searching the entire $PATH every time you want to run something. Cool, until it goes bad (which invariably will happen). Your file may have ended up in the hash table, then you moved the file and the hash table didn't get updated. Now bash looks in its hash table, finds the filename there, but with the OLD path. It then tries to run it from the old location (where it isn't any more).
Autocompletion finds the file because it doesn't use the PATH hashing.

Try typing "hash -r" and run your commands again.

Just a guess.

[DeletedAccount]

Hi,
I am almost 90% sure that executable you are trying to run is not valid on the platform you are trying to run . I can say this since I have played around with lots of distro's , I haven't really seen a nix for more than a year or so now , but best thing for you would get the development environment of the handheld and chroot into it and diagnose the problem . I am not really sure whether strace would bring anything useful , But as always I may be completely wrong --- > I am a moron .

Regards
Shrek