I simply want to run an executable from the command line, ./arm-mingw32ce-g++
, but then I get the error message,
bash: ./arm-mingw32ce-g++: No s
Added here for future reference (for users who might fall into the same case): This error happens when working on Windows (which introduces extra characters because of different line separator than Linux system) and trying to run this script (with extra characters inserted) in Linux. The error message is misleading.
In Windows, the line separator is CRLF (\r\n) whereas in linux it is LF (\n). This can be usually be chosen in text editor.
In my case, this happened due to working on Windows and uploading to Unix server for execution.
I had the same problem with a file that I've created on my mac. If I try to run it in a shell with ./filename I got the file not found error message. I think that something was wrong with the file.
what I've done:
open a ssh session to the server
cat filename
copy the output to the clipboard
rm filename
touch filename
vi filename
i for insert mode
paste the content from the clipboard
ESC to end insert mode
:wq!
This worked for me.
I got the same error for a simple bash script that wouldn't have 32/64-bit issues. This is possibly because the script you are trying to run has an error in it. This ubuntu forum post indicates that with normal script files you can add 'sh' in front and you might get some debug output from it. e.g.
$ sudo sh arm-mingw32ce-g++
and see if you get any output.
In my case the actual problem was that the file that I was trying to execute was in Windows format rather than linux.
As mentioned by others, this is because the loader can't be found, not your executable file. Unfortunately the message is not clear enough.
You can fix it by changing the loader that your executable uses, see my thorough answer in this other question: Multiple glibc libraries on a single host
Basically you have to find which loader it's trying to use:
$ readelf -l arm-mingw32ce-g++ | grep interpreter
[Requesting program interpreter: /lib/ld-linux.so.2]
Then find the right path for an equivalent loader, and change your executable to use the loader from the path that it really is:
$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g++
You will probably need to set the path of the includes too, you will know if you want it or not after you try to run it. See all the details in that other thread.
This error can mean that ./arm-mingw32ce-g++
doesn't exist (but it does), or that it exists and is a dynamically linked executable recognized by the kernel but whose dynamic loader is not available. You can see what dynamic loader is required by running ldd /arm-mingw32ce-g++
; anything marked not found
is the dynamic loader or a library that you need to install.
If you're trying to run a 32-bit binary on an amd64 installation:
:i386
packages in addition to the :amd64
packages.I just had this issue in mingw32 bash
. I had execuded node/npm from Program Files (x86)\nodejs
and then moved them into disabled
directory (essentially removing them from path). I also had Program Files\nodejs
(ie. 64bit version) in path, but only after the x86 version. After restarting the bash shell, the 64bit version of npm could be found. node
worked correctly all the time (checked with node -v
that changed when x86 version was moved).
I think bash -r
would've worked instead of restarting bash: https://unix.stackexchange.com/a/5610