Search code examples
c++windowsgccandroid-ndkcygwin

"no input files" when building with gcc of Android NDK r6b


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?


Solution

  • 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.