Linux claiming android (arm-eabi-gcc) is not present when it is clearly there

Question

So I just trying to build a library using the NDK. I believe that the Android.mk and Application.mk files are correct, but whether they are or not is irrelevant.

when executing make APP=hello within the NDK directory

Android NDK: Building for application 'hello'
make: ./build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/arm-eabi-gcc: Command not found
Compile thumb : hello <= apps/ssa/project/jni/hello/.c
/bin/sh: ./build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/arm-eabi-gcc: not found
make: ** [out/apps/ssa/armeabi/objs/hello/hello/*.o] Error 127

So from here I decided to go look and see where the file was.

cd build/prebuild/linux-x86/arm-eabi-4.4.0/bin/

The output of ls -l clearly shows the file to exist:

...
-rwxr-xr-x 1 bpescato bpescato  238680 2010-05-03 18:24 arm-eabi-g++
-rwxrwxrwx 1 bpescato bpescato  234520 2010-08-20 09:27 arm-eabi-gcc
-rwxr-xr-x 1 bpescato bpescato  234520 2010-05-03 18:24 arm-eabi-gcc-4.4.0
...

So I next try to simply execute it and allow it tell me the usage:

$ ./arm-eabi-gcc

bash: ./arm-eabi-gcc: No such file or directory

Then, just to make sure I'm not crazy:

$ less arm-eabi-gcc

"arm-eabi-gcc" may be a binary file. See it anyway?

Sure enough, viewing the file displays a whole lot of binary data which is clearly present and on disk.

Does anyone have any idea what is going on?

Answer 1

The file has different permissions and modification time from the two neighboring files, which makes me wonder if something mangled it a bit. (Try "cmp arm-eabi-gcc arm-eabi-gcc-4.4.0", should be the same.)

Does "ldd arm-eabi-gcc" report any missing libraries? What I'm thinking is that the file that is missing isn't "arm-eabi-gcc" itself, but rather something upon which it depends.

Next step would be "strace ./arm-eabi-gcc" to see what system calls it's making.

Answer 2

Thank you fadden for the response, however it turns out that my issue was related to the fact that my VM was (unbeknownst to me) a 64 bit machine, and I was trying to run a 32 bit executable.

So, to fix the problem and keep the machine intact I would need to have followed the 64 bit instructions.

Since many of the forums reference 32 bit android ndk help, I decided to just get a new 32 bit VM.