0

After returning from NY holidays I've faced a queer problem with building the projects I hadn't had any similar problems before.
Each project is a shared/static library or an application for Android built with NDK 6b using gcc cross-compiler (cygwin).
The OS is Windows 7 (32-bit), and I haven't installed/uninstalled/reinstalled any relevant software (during holidays :).

I've tried to build the standard NDK sample hello-jni - same error occurs.
The log:

A.User@A-User-L ~/Devel/hello-jni
$ ndk-build
Gdbserver      : [arm-linux-androideabi-4.4.3] libs/armeabi/gdbserver
Gdbsetup       : libs/armeabi/gdb.setup
Compile thumb  : hello-jni <= hello-jni.c
arm-linux-androideabi-gcc.exe: /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/jni/hello-jni.c: No such file or directory
arm-linux-androideabi-gcc.exe: no input files
/cygdrive/c/dev/Android/android-ndk-r6b/build/core/build-binary.mk:217: recipe for target `/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o' failed
make: *** [/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o] Error 1

The verbose log (sorry for overwhelming with letters):

A.User@A-User-L ~/Devel/hello-jni
$ ndk-build V=1
rm -f /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi/lib*.so /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi-v7a/lib*.so /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/x86/lib*.so
rm -f /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi/gdbserver /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi-v7a/gdbserver /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/x86/gdbserver
rm -f /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi/gdb.setup /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi-v7a/gdb.setup /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/x86/gdb.setup
Gdbserver      : [arm-linux-androideabi-4.4.3] libs/armeabi/gdbserver
mkdir -p /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi
install -p /cygdrive/c/dev/Android/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/gdbserver /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi/gdbserver
Gdbsetup       : libs/armeabi/gdb.setup
mkdir -p /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi
echo "set solib-search-path /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi" > /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi/gdb.setup
echo "directory /cygdrive/c/dev/Android/android-ndk-r6b/platforms/android-8/arch-arm/usr/include /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/jni /cygdrive/c/dev/Android/android-ndk-r6b/sources/cxx-stl/system" >> /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/libs/armeabi/gdb.setup
Compile thumb  : hello-jni <= hello-jni.c
/cygdrive/c/dev/Android/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-gcc -MMD -MP -MF /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org -fpic  -ffunction-sections  -funwind-tables  -fstack-protector  -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__  -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__   -Wno-psabi -march=armv5te  -mtune=xscale  -msoft-float  -mthumb  -Os  -fomit-frame-pointer  -fno-strict-aliasing  -finline-limit=64  -I/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/jni  -DANDROID  -Wa,--noexecstack  -O0 -g  -I/cygdrive/c/dev/Android/android-ndk-r6b/platforms/android-8/arch-arm/usr/include  -c   /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/jni/hello-jni.c -o /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o &&  ( if [ -f "/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org" ]; then  awk -f /cygdrive/c/dev/Android/android-ndk-r6b/build/awk/convert-deps-to-cygwin.awk /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org > /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d &&  rm -f /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org;  fi )
/cygdrive/c/dev/Android/android-ndk-r6b/build/core/build-binary.mk:217: recipe for target `/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o' failed
arm-linux-androideabi-gcc.exe: /cygdrive/e/Users/A.User.ORG/Devel/hello-jni/jni/hello-jni.c: No such file or directory
arm-linux-androideabi-gcc.exe: no input files
make: *** [/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o] Error 1

The content of Android.mk is pretty standard:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := hello-jni
LOCAL_SRC_FILES := hello-jni.c

include $(BUILD_SHARED_LIBRARY)

I know that cygwin on Windows doesn't support symbolic links - there are no symbolic links in the directories tree.
There is no cruel antivirus running, just Windows Defender.
I run the build as an ordinary user as I used to do last year (i.e. no credential changes).

What may be wrong?

Related issues:

[Update] Process Monitor shows that the cross-compiler tries to access the "wrong path": `E:\cygdrive\e\Users\A.User.ORG\Devel\hello-jni\jni\hello-jni.c`... I wonder how this tool worked before! More info is to follow as soon as I dig it up :)
[Update#2] On another PC (Windows XP 32-bit) which has almost the same set of tools installed (same version of Cygwin, Android NDK), the log looks different: 
Compile thumb  : hello-jni <= hello-jni.c
/cygdrive/c/dev/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-gcc -MMD -MP -MF E:/Users/A.User.SURC/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org -fpic -ffunction-sections -funwind-tables -fstack-protector -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__  -Wno-psabi -march=armv5te -mtune=xscale -msoft-float -mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -IE:/Users/A.User.SURC/Devel/hello-jni/jni -DANDROID  -Wa,--noexecstack -O0 -g -IC:/dev/android-ndk-r6b/platforms/android-8/arch-arm/usr/include -c  E:/Users/A.User.SURC/Devel/hello-jni/jni/hello-jni.c -o E:/Users/A.User.SURC/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o && ( if [ -f "E:/Users/A.User.SURC/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org" ]; then awk -f /cygdrive/c/dev/android-ndk-r6b/build/awk/convert-deps-to-cygwin.awk E:/Users/A.User.SURC/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org > E:/Users/A.User.SURC/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d && rm -f E:/Users/A.User.SURC/Devel/hello-jni/obj/local/armeabi/objs-debug/hello-jni/hello-jni.o.d.org; fi )

For some unclear reasons gcc is fed with Windows-style paths here... and this is how the processes should interact.
So the question now is how to instruct cygwin/NDK to pass proper paths?

AntonK
  • 1,210
  • 1
  • 16
  • 22

2 Answers2

0

Is the source code file in the correct directory? Check the path printed in the error message. c/c++ source files have to be in the jni sub directory, not the src one.

Also, not sure if that helps, the latest SDK/NDK versions should support Windows native batch files. Cygwin is no longer required (debugging support is still lacking though). Try to build from the windows command line running ndk-build.

Also, did the same setup work before (on the same machine with same files/directories)?

Mario
  • 35,726
  • 5
  • 62
  • 78
  • The full path to the file is `E:\Users\A.User.ORG\Devel\hello-jni\jni\hello-jni.c`, so it exists, and accessible via `/cygdrive/e/Users/A.User.ORG/Devel/hello-jni/jni/hello-jni.c` (see also the update in my question). – AntonK Jan 12 '12 at 11:15
  • Unfortunately it is not the option to update SDK/NDK, because the project is not in the proper phase for that. And `ndk-build` (in the real project) is invoked via bash-scripts, which rely on cygwin. Running `ndk-build` from the Windows command line doesn't work because this tool isn't able to find the "compatible GNU make" (I believe, it is the problem with NDK 6b). – AntonK Jan 12 '12 at 11:21
  • The missing make could be solved by installing MinGW and then adding its bin dir to PATH (might require a symlink from "make" to "mingw32-make" though). Are you able to open the c file from cygwin, e.g. printing it using 'cat hello-jni.c'? EDIT: Just read your update. Did you set your environment variables in cygwin? it might use those from the windows environment using the native paths? – Mario Jan 12 '12 at 14:04
  • thanks a lot for trying to help me with solving the issue! Yes, I know there is another `make` in MinGW. I will take a closer look at it some day... So far I'm interested to have my cygwin-based system back on track. I've found the cause of the problem - see [my answer](http://stackoverflow.com/a/8841150/536172). – AntonK Jan 12 '12 at 19:41
0

I've finally tracked down the cause of the problems on my PC with ndk-build.
In short: it was caused by the conflict between cygwin's mount and mount.exe, which is a part of the feature "Client for NFS" (I indeed have installed it recently along with Telnet Client).

More information

I've found a similar problem mentioned in the article "Building Necessitas Qt framework using NDK-r5b and Cygwin" - the person had encountered issues with NDK include paths, which he solved by modifying the scripts.
This hint helped me to locate the corresponding script gen-windows-host-path.awk in NDK, which performs the paths transformation (from cygwin-style to Windows).
It relies on mount, which lists all drives when called without parameters.
And it turned out that mount on my PC didn't see any drives... because it was mount.exe at /cygdrive/c/Windows/system32/ from Windows, and not /usr/bin/mount from Cygwin.
By default mount.exe is not present in Windows, and if this is the case then you probably have installed "Client for NFS".
So the solution (actually a workaround) is to uninstall "Client for NFS" feature from Windows.

Community
  • 1
  • 1
AntonK
  • 1,210
  • 1
  • 16
  • 22
  • Ah, very interesting. Odd it isn't called using an absolute path, though. Might be fixed in newer versions. If not, you should write them a bug report ticket. – Mario Jan 12 '12 at 22:13