No such file or Directory

[nymar]

Hi
When i run an existing executable i got

Code: Select all

[root@raspberrypi examples]# ./cancount
-sh: ./cancount: No such file or directory

I give you the following outputs

Code: Select all

[root@raspberrypi examples]# file cancount
cancount: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Code: Select all

4904 8 -rwxrwxrwx 1 root root 6864 Apr 19 14:42 cancount*
4897 8 -rw------- 1 root root 5232 Apr 19 14:42 cancount.c

[joan]

The file's name appears to be cancount* not cancount.

[nymar]

well when i push Tab key it only recognize cacount but i tried to run cancount* and it's the same. I don't think that's the problem

[joan]

What does

ldd cancount

report?

[nymar]

ldd command not found

[sdjf]

Any time you get "command not found," it means you need to install it. Should be in repository, but is not there as a single command. Must be in one of the utility packages.

[Joe Schmoe]

In response to:

ldd command not found

Any time you get "command not found," it means you need to install it. Should be in repository, but is not there as a single command. Must be in one of the utility packages.

That's not correct/relevant, since the point of this thread is that, in the OP's specific case, the file *does* exist, yet for some reason, trying to run it generates a "not there" type message. In any case, it would be virtually impossible for the "ldd" command to not be installed. So, I think we should assume that "ldd" *is* installed, and that the above message was probably not quite cut-and-pasted verbatim - and that ldd was complaining about not being able to load the executable.

Yes, ldd is cryptic - that's the essence of this thread, that you're getting an error message that makes no sense.

FWIW, this can happen if the executable is for another architecture - which is a hazard when working with non-x86 Linuxes - you often try to bring over and execute an x86 binary, forgetting that, as they say, "We're not in Kansas anymore".

[joan]

ldd command not found

Could you cut and paste the command you enter as well as the response?

[nymar]

In response to:

ldd command not found

Any time you get "command not found," it means you need to install it. Should be in repository, but is not there as a single command. Must be in one of the utility packages.

That's not correct/relevant, since the point of this thread is that, in the OP's specific case, the file *does* exist, yet for some reason, trying to run it generates a "not there" type message. In any case, it would be virtually impossible for the "ldd" command to not be installed. So, I think we should assume that "ldd" *is* installed, and that the above message was probably not quite cut-and-pasted verbatim - and that ldd was complaining about not being able to load the executable.

Yes, ldd is cryptic - that's the essence of this thread, that you're getting an error message that makes no sense.

FWIW, this can happen if the executable is for another architecture - which is a hazard when working with non-x86 Linuxes - you often try to bring over and execute an x86 binary, forgetting that, as they say, "We're not in Kansas anymore".

you don't help me with that any solution you can propose ?

[jojopi]

If an executable is for completely the wrong architecture, you will get "Exec format error". If libraries are missing you will get "error while loading shared libraries". If the binary is compiled for the right architecture but the wrong CPU variant, you may get "Illegal instruction".

If you get "No such file or directory", that means the kernel recognises the binary as being valid, but the dynamic loader path embedded in the binary does not exist on the system. That could be due to an incompatible ABI, such as a hard/soft float mismatch or 32/64 bit on platforms that can run both. (If the loader path is ambiguous, you may get "wrong ELF class" in the latter case.) You may be able to support the ABI by installing compatibility packages, or in some cases just with a symlink between two ld-linux paths.

OP appears to have the C source code in the same directory as the executable, so I wonder if s/he has tried compiling it again. If a distribution cannot run executables created with its own compiler then it is rather broken.

[nymar]

Could you cut and paste the command you enter as well as the response?

[root@raspberrypi examples]# ldd cancount
-sh: ldd: command not found

[PS1981]

Just to be sure:

You are typing a lower case "L" and not an upper case "i" in ldd aren't you?

[nymar]

yea lower case "L" ldd=LDD

[topguy]

well when i push Tab key it only recognize cacount but i tried to run cancount* and it's the same. I don't think that's the problem

Have you compiled this program yourself on the Pi ?

The command shell treats "*" as a special character. If you need to run commands with strange characters you need to escape them, so either:

Code: Select all

"./cancount*"
or
./cancount\*

might work.

[nymar]

same "No such .."
Look when i compile them in my PC they have no * but when i send them to RPI they got this *

[joan]

The * at the end of the file name probably just indicates it's an executable file. It's a display option which I thought defaulted to off.

Your installation appears to be corrupt.

It may well be safest to reinstall to get back to a known safe state.

[jojopi]

Your installation appears to be corrupt.
It may well be safest to reinstall to get back to a known safe state.

OP seems to admit that the executable is compiled on a remote system. So probably best to reinstall that machine as well?

[nymar]

reinstall what guyz ??

[joan]

Your situation is confusing.

ldd fails but ls works?

On the Pi could you cut and paste the following commands and show us the output.

Code: Select all

pwd
ls -l
echo $PATH
ldd
whoami

On my machine I get the following

root@soft:~# pwd
/root
root@soft:~# ls -l
total 8
-rwxr-xr-x 1 root root 76 Apr 13 07:15 save-state-files
-rw-r--r-- 1 root root 288 Apr 13 08:43 soft-state-files
root@soft:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@soft:~# ldd
ldd: missing file arguments
Try `ldd --help' for more information.
root@soft:~# whoami
root
root@soft:~#

[sdjf]

As others have said, the file name appears to be cancount*. But, the asterisk * is a special character that linux considers a wild card, rather than a simple character. To tell linux that you do not want the * to be a wild card, you put the name of the file in quotes, or preface the asterisk with a backslash, again, as someone else pointed out.

I would suggest renaming the executable on linux to not have the asterisk in it, so you do not have to keep doing what we call "escaping the special character," to make it easier to debug what is going on.

You said the file was compiled on another machine. How? And does it require arguments? If it requires input or arguments, then the "not found" message you are getting may be telling you that "cancount*" is not finding any arguments or input.

[nymar]

Code: Select all

[root@raspberrypi ~]# pwd
/root
[root@raspberrypi ~]# ls -l
total 16
-rw-r--r-- 1 root root 2252 Apr 22 13:02 azerty.k
-rw-r--r-- 1 root root 2252 Apr 22 13:02 azerty.kmap
-rw-r--r-- 1 root root  572 Apr 22 13:02 data.txt
drwxr-xr-x 2 root root 4096 Apr 22 13:02 examples/
[root@raspberrypi ~]# echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/bin
[root@raspberrypi ~]# ldd
-sh: ldd: command not found
[root@raspberrypi ~]# whoami
root
[root@raspberrypi ~]# 

[joan]

ldd should be present on your Pi by default.

Unless you have made a lot of changes to your Pi I'd back up any files you need and reinstall your Pi from a fresh image.

[jojopi]

As others have said, the file name appears to be cancount*.

Everyone who has said that clearly did not read the original post carefully enough. Specifically, the output from "file" shows that the binary is indeed called "cancount". The reference to "cancount*" is in the output of an "ls -lisF".

If it requires input or arguments, then the "not found" message you are getting may be telling you that "cancount*" is not finding any arguments or input.

It is highly unlikely that the binary itself is printing the message "-sh: ./cancount: No such file or directory". That error, when the file does in fact exist, basically can only mean that the dynamic loader required by the binary is not present.

Since at least some binaries work, there must be a dynamic loader present. So the suspect binary is evidently compiled to use a different loader path than the rest of the system. Compiling the program locally should fix that, as might the command:

Code: Select all

ln -s ld-linux.so.3 /lib/ld-linux-armhf.so.3

Not having an "ldd" command is certainly unusual, and it may or may not be part of a bigger problem. But it is really not required to diagnose or fix the original issue.

[drirr]

ldd is part of the "glibc" package, which is kinda vital. Have you replaced glibc with something else (uclibc?)? If not, try reinstalling glibc and see if that helps in anyway.

[Joe Schmoe]

It is highly unlikely that the binary itself is printing the message "-sh: ./cancount: No such file or directory". That error, when the file does in fact exist, basically can only mean that the dynamic loader required by the binary is not present.

Wouldn't it be funny if this whole thread boils down to:

pts/2 pi@raspberrypi ~ $ printf '#include <stdio.h>\nint main(void) { puts("-sh: ./cancount: No such file or directory"); return 0; }' | gcc -xc - -o cancount
pts/2 pi@raspberrypi ~ $ ./cancount
-sh: ./cancount: No such file or directory
pts/2 pi@raspberrypi ~ $

Silly OP...