CODEWITHSUNDEEP
linuxgccmakefileandroid-ndk
JSBattista
JSBattista

Reputation: 41

Multiple sysroot results in gcc calls from makefile to erroneous assume Android NDK path.

This is a most vexing issue. When I run my makefile I see two sysroot in the output:

    ubuntu@ubuntu:~/Desktop/LatestAndroidstuff/CmE_source_DAL_1.7_3564/CmCompact$ make
platform/wince/WibuCmHID/rules.mak:31: WibuCmHID only for Windows CE
/home/ubuntu/my-android-toolchain/bin//arm-linux-androideabi-gcc  -I./ -I./external/hidapi/include  -Os  -std=c99 -Wall -Wextra -fno-short-enums -fno-strict-aliasing --sysroot=/home/ubuntu/my-android-toolchain/sysroot --sysroot=/home/ubuntu/android-ndk-r13b/platforms/android-14/arch-arm  -o obj/release/android/armeabi-v7a/static/w_refcount.o -c   base/w_refcount.c 
In file included from base/w_refcount.c:29:0:
./base/w_define.h:31:19: fatal error: stdio.h: No such file or directory
 #include <stdio.h>
                   ^
compilation terminated.
rules.mak:54: recipe for target 'obj/release/android/armeabi-v7a/static/w_refcount.o' failed
make: *** [obj/release/android/armeabi-v7a/static/w_refcount.o] Error 1

If I edit the failing command and remove the extra sysroot (the second one), it works. 

/home/ubuntu/my-android-toolchain/bin//arm-linux-androideabi-gcc  -I./ -I./external/hidapi/include  -Os  -std=c99 -Wall -Wextra -fno-short-enums -fno-strict-aliasing --sysroot=/home/ubuntu/my-android-toolchain/sysroot --sysroot=/home/ubuntu/android-ndk-r13b/platforms/android-14/arch-arm  -o obj/release/android/armeabi-v7a/static/w_refcount.o -c   base/w_refcount.c

Problem is, I have looked all over the makefile. The makefile is simple enough:

WBSMAK_ANDROID_NDK_HOME=/home/ubuntu/android-ndk-r13b
SYSROOT=/home/ubuntu/my-android-toolchain/sysroot
ANDROID_TOOLCHAIN_DIR=/home/ubuntu/my-android-toolchain/bin/
WBSMAK_ANDROID_CC=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-gcc
WBSMAK_ANDROID_LD=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ld
WBSMAK_ANDROID_AR=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ar
WBSMAK_ANDROID_RANLIB=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ranlib

SHELL       := /bin/bash
AR          := WBSMAK_ANDROID_AR
CC          ?= WBSMAK_ANDROID_CC
LD          ?= WBSMAK_ANDROID_LD
RANLIB      := WBSMAK_ANDROID_RANLIB

In order to make the file pick up sysroot:

CFLAGS_ARCH := --sysroot=${SYSROOT}

But there is no mention at all in the makefile about that other second sysroot nor that path that shows up. Also, I looked and made sure it's not picking up an environment variable.

ubuntu@ubuntu:~/my-android-toolchain$ printenv | grep SYSROOT
ANDROID_SYSROOT=
LINARO_SYSROOT=/home/ubuntu/linaro-toolchain-4.6/arm-unknown-linux-gnueabi/sysroot
SYSROOT=/home/ubuntu/my-android-toolchain/

The environment sysroot it pointed to where I want it. If I move the Android NDK folder and all its stuff out of the path, that is nowhere in the makefile, then I get the error. If I have the folder where the extra sysroot is, then the library compiles and links, but it crashes on the Android device, which is Android 21, not 14. I don't know why it's always Android 14. Could I be missing some setting somewhere? Perhaps when I created the standalone tools using make-standalone-toolchain.sh something hardcoded went in so the calls to /home/ubuntu/my-android-toolchain/bin/arm-linux-androideabi-gcc always searches for the android-14 path?

Very vexing problem. I have been all over the makefile. I don't know why the gcc keeps picking up that android 14 sysroot. Could I be only providing for the compilation but the linking is pulling up a default sysroot?

Upvotes: 3

Views: 1575

Answers (1)

JSBattista
JSBattista

Reputation: 41

Alright the issue appears to have been a carefully sidelines .mak file in a subfolder that was looking for a string in a string of an existing field and on finding that, was using ANDROID_ARCH for the --sysroot in the actual gcc call. But to the credit of who wrote it, it did have the other -march setting needed for proper compile and linking of the android native module.

Moral of the story: always surf around the folders and take a glance at everything.

(of course my app still crashes but that's another matter to find that out... )

Upvotes: 1

Related Questions