I'm building an OpenGL based app - writing in native C/C++.
I want to have my native files in a single location and only linked to the project ( so when I edit them in XCode/Eclipse the other project already has the updated files ). However, I can't figure out how to get ndk-build to build files that aren't actually in the JNI folder. Symbolic links ( in OSX ) didn't do the trick.
I keep getting
make: *** No rule to make target `/Developer/SDKs/android-ndk-r7b/build/core/myfile.cpp', needed by `obj/local/armeabi/objs/glHelloArrow/myfile.o'. Stop.
Any ideas?
I build outside of JNI folder on Windows. My Android.mk includes a makefile in a different folder:
LOCAL_PATH := $(MY_WORKSPACE)/path/jni
include $(MY_WORKSPACE)/path/jni/Src.mk
where the actual sources are listed:
LOCAL_SRC_FILES := \
a.cpp \
b.cpp \
etc.
One caveat is - make does not work right with relative paths. Or rather, it does, but assumes the path to be relative to the current folder, which in case of the ndk-build process can be all over the place. Thus the env variable that denotes the root of the file location.
Some details here.
I have a similar issue with cross-platform codebase. I've not found any way to do this.
My workaround is to create a symlink from my source code root directory into jni, so I can give the NDK build system paths like jni/link/common/foo.c.
Just be sure that you remove the symlink if you ever need to run tools that do recursive directory traversals...
Related
I have multiple static libs that are built using jni. I have a scheme that includes other mk files, etc to allow me to share compile settings, include files from other dependent projects, etc.
I have set it up successfully on the mac and have been building it. However, when I tried to do the same in windows under cygwin I'm running into issues...
Here is my jni/Android.mk file..
LOCAL_PATH := $(call my-dir)
INJ_PROJECT_PATH := $(PWD)
include $(INJ_PROJECT_PATH)/jni/Project.mk
The problem I'm seeing is that ndk-build is complaining about the Project.mk file. Here is what I'm seeing..
shammi#SHAMMIDEV /cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core
$ ndk-build.cmd NDK_APP_OUT=../../build/Android/Engine/release
jni/Android.mk:5: /cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core/jni/Project.mk: No such file or directory
jni/Android.mk:5: /cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core/jni/Project.mk: No such file or directory
jni/Android.mk:5: /cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core/jni/Project.mk: No such file or directory
jni/Android.mk:5: /cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core/jni/Project.mk: No such file or directory
C:/projects/Android/sdk/ndk-bundle/build//../build/core/build-all.mk:89: Android NDK: WARNING: There are no modules to build in this project!
make: *** No rule to make target `/cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core/jni/Project.mk'. Stop.
I have confirmed that /cygdrive/c/projects/injitiProjects/injitiEngine/Engine/Core/jni/Project.mk does exist, and I am the owner and it has read permissions for user/group/other.
Again, this exact same setup works absolutely fine on the mac. I'm just looking at having a portable dev environment.
What am I missing here..?
I guess I forgot that ndk-build.cmd was a windows shell batch script (DOH).
The answer was that I was able to call /build/ndk-build which is a sh script that is comfortable running in cygwin.
You probably need to use LOCAL_PATH instead of PWD. I'm not really sure how PWD gets set (I think it's a make builtin?), but we actually have control over LOCAL_PATH and can make sure it gets set in the right way for cygwin.
Instead of include what if you define it to be APP_BUILD_SCRIPT?
for ex.
APP_BUILD_SCRIPT := jni/Android.mk
Also Id try $(shell $pwd) instead of $(PWD) if the above doesn't work, usually ndk doesn't interpret shell commands for me if I don't use the shell in the parenthesis.
We are attempting to add first class build support for Android to a C++ library. We want to supply a stock Android.mk, and disgorge it from dependencies like a jni subfolder in an Eclipse or Android Studio project directory. That is, we want to:
cd library-src
ndk-build <options>
In the above, library-src is not NDK_PROJECT_PATH. Rather, its the root folder for the library.
We visited the NDK's help (ndk-build -?), but it did not tell us how to remove the assumptions. We tried the following, but it produced an errors:
$ ndk-build -f Android.mk
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
/opt/android-ndk-r10e/build/core/build-local.mk:143: *** Android NDK: Aborting
Stop.
Attempting to set NDK_PROJECT_PATH results in a similar error:
$ NDK_PROJECT_PATH=. ndk-build -f Android.mk
Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk
/opt/android-ndk-r10e/.../add-application.mk:199: *** Android NDK: Aborting...
Stop.
And attempting to set APP_BUILD_SCRIPT results in a similar error:
$ NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=Android.mk ndk-build -f Android.mk
Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk
/opt/android-ndk-r10e/.../add-application.mk:199: *** Android NDK: Aborting...
Stop.
How do we use ndk-build without the jni directory?
Its important that we remove the limitations/assumptions. If we can't remove them, then we can't automate building and testing. If we can't automate building and testing, then we can't add the support because our governance has some QA and testing gates that we won't be able to pass through. (I'm willing to tolerate a manual adb push to test on-device).
I must admit that I don't understand your limitations. Why adding file library-src/Android.mk is OK, but library-src/jni/Android.mk breaks your QA and testing gates. Furthermore, Android.mk is usually not enough to launch a build. Whether you want to choose the STL variation, or ABI, or toolchain, it is natural to define these settings in a different file, Application.mk, which also goes to the jni directory by convention. Add library-src/jni directory, and Android developers will thank you when their tools of trade get upgrades and they can stay with the standard configuration.
But Android build is a very flexible system, and you can achieve literally what you ask for.
The experiments that you made did not work because ndk-build is simply a thin wrapper around GNU make, and treats environment variables with low priority.
ndk-build APP_BUILD_SCRIPT=Android.mk NDK_PROJECT_PATH=.
will most likely simply work for you. If you need more control, you can use something like
ndk-build APP_BUILD_SCRIPT=Android.mk NDK_PROJECT_PATH=. APP_STL=gnustl_static APP_ABI=armeabi-v7a APP_PLATFORM=android-19 NDK_TOOLCHAIN_VERSION=4.9
You can control the output directories, too. See NDK_APP_OUT, NDK_APP_LIBS_OUT.
One last hint: if your global build process is based on make, you can invoke $(MAKE) directly instead of going through ndk-build. It is also OK if you require standalone toolchain to keep platform-independent make logic.
I have tried scouring the Internet and StackOverflow (too many articles to count) but cannot find assistance that is all of these things:
More recent than 2013
Does not require Cygwin if developing
on Windows
Is geared to Android Studio, NOT Eclipse.
I am diving head first into Android development for the very first time and the project I have newly joined depends on developing with the NDK. I've been reading the docs that come with the NDK but have run into a stone wall with this sample.
I am trying to build hello-jni, the sample project within the NDK. Here is my environment:
Android Studio 1.4 (most up to date, stable version currently available)
NDK version: r10e
OS: Windows 7
Contents of Application.mk file:
APP_ABI := all64 // Came with 'all', read somewhere on SO that it
// should be 'all64'. Result is the same.
Contents of Android.mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
My PATH environment variable includes a path to my NDK root folder and to \prebuilt\windows-x86_64\bin (because I read on one of many articles that it should.) When I navigate to the hello-jni root folder though, and call ndk-build, I am only presented with errors.
c:\NDK\android-ndk-r10e\build\core\build-local.mk:40: c:/NDK/android-ndk-r10e/build/core/build/core/init.mk: No such file or directory
c:\NDK\android-ndk-r10e\build\core\build-local.mk:191: \add-application.mk: No such file or directory
c:\NDK\android-ndk-r10e\build\core\build-local.mk:206: \setup-imports.mk: No such file or directory
c:\NDK\android-ndk-r10e\build\core\build-local.mk:223: \build-all.mk: No such file or directory
make.exe: *** No rule to make target `\build-all.mk'. Stop.
If anything else is required for people to assist me, say the word I will provide what I can. All help will be greatly appreciated.
EDIT:
Most of the articles of I've seen for Windows mention Cygwin, but according to the docs, it isn't needed. If this is incorrect, please correct me?
Except from \android-ndk-r10e\docs\Programmers_Guide\html\md_3__key__topics__building__s_t_a_n_d_a_l_o_n_e-_t_o_o_l_c_h_a_i_n.html
Windows support
The Windows binaries do not depend on Cygwin. The good news is that they are thus faster, the bad news is that they do not understand the Cygwin path specification like /cygdrive/c/foo/bar (instead of C:/foo/bar).
The NDK build system ensures that all paths passed to the compiler from Cygwin are automatically translated, and deals with other horrors for you. If you have a custom build system, you may need to deal with the problem yourself.
I can't take the credit for this answer, a coworker kindly sleuthed it out for me. When he found the answer, I demanded to know what else he had done, because clearly I must have missed some magic? I only saw him switch two lines in a make file, there had to be more? Alas, no. This alone was the source of my woe.
While I'm hesitant to call it an error within the NDK because I don't know how it works with Cygwin, neither of us can understand how this has ever worked for anyone building in native Windows, as the line I will be referencing is recorded in the git repository as being added back in 2011 or 2010. ( https://android.googlesource.com/platform/ndk/+/master/build/core/build-local.mk )
To aid explanation, here is the first line of my error again:
c:\NDK\android-ndk-r10e\build\core\build-local.mk:40: c:/NDK/android-ndk-r10e/build/core/build/core/init.mk: No such file or directory
The first file that is unable to found is ...build/core/build/core/init.mk, which of course doesn't exist because build/core should not be repeated.
The command that begins the build, ndk-build.cmd, calls build\core\build-local.mk to begin the process. Inside this file the environment variable, NDK_ROOT, is recreated upon entry. Whatever my NDK_ROOT is, is irrelevant.
NDK_ROOT := $(dir $(lastword $(MAKEFILE_LIST)))
NDK_ROOT := $(strip $(NDK_ROOT:%build/core/=%))
NDK_ROOT := $(subst \,/,$(NDK_ROOT))
NDK_ROOT := $(NDK_ROOT:%/=%)
.
.
.
The second line strips the end of the current directory (the build/core/) from the end of my new NDK_ROOT, because the true root should be the parent directory of build and because it will be added back later to find all those 'missing' files. That's fine, except note the forward-slashes (/) used in the search. Windows does not use (or in my experience at least, usually does not return) forward-slashes, though it will often parse them if that is what it's given. (When changing directories, for example, I've found either to be acceptable as long as I already know where I need to go. Tab completion does not seem to function if my path ends with a /.)
Oh, but look at the third line (added way back in 2011)! A substitution is made of every backslash (\) in NDK_ROOT, replaced with forward-slash (/). So the replacement of build/core/ should go off without a hitch, right? Problem: it's too late.
The strip call has already occurred and if the NDK_ROOT received a path with backslashes instead of forward-slashes, build/core/ is never found and stripped from the variable. How did my coworker fix it? Easy. He switched the lines around:
NDK_ROOT := $(dir $(lastword $(MAKEFILE_LIST)))
NDK_ROOT := $(subst \,/,$(NDK_ROOT))
NDK_ROOT := $(strip $(NDK_ROOT:%build/core/=%))
NDK_ROOT := $(NDK_ROOT:%/=%)
My hello-jni project now builds, along with Teapot, another sample from the NDK, which I tried just to be sure. And so does native-audio, native-codec, native-media, and More Teapots. Haven't tried to run them yet... but I have no build errors.
I don't know if this fix will break Cygwin users, I don't have that on my box. I also don't know if it would break Linux environments because I don't have Linux on my box. But this may help native Windows users, and I hope so, because I uselessly beat my head on this for 3 or 4 days and read more SO articles than I ever care to at once.
Using a windows machine I encountered this error but it was saying the clear-vars.mk : No such file or directory. After I looked at the ndk-build.cmd in the directory
C:\Users\\AppData\Local\Android\Sdk\ndk-bundle\build
the file looks like this
#echo off
set NDK_ROOT=%~dp0\..
set PREBUILT_PATH=%NDK_ROOT%\prebuilt\windows-x86_64
if exist %PREBUILT_PATH% goto FOUND
set PREBUILT_PATH=%NDK_ROOT%\prebuilt\windows
:FOUND
"%PREBUILT_PATH%\bin\make.exe" -f "%NDK_ROOT%\build\core\build-local.mk" SHELL=cmd %*
But you will also find the same file name under directory
C:\Users\jmatthews\AppData\Local\Android\Sdk\ndk-bundle
and the file looks like this
#echo off
%~dp0\build\ndk-build.cmd %*
remove the second line so it looks like this with only 1 line echo off
#echo off
This file is called and messes up the Windows directory structure. After that I was able to compile on windows. Also I had issues with the project using a space in the directory so move your project location to directories without spaces.
I have glibc compiled for arm which is different from Android glibc or the bionic C as the glibc environment I have complied will help in providing more api's.
Now I can copy the glibc environment on /system/ folder while Android is running, and on doing chroot I can run my programs on glibc environment.
Currently I am compiling glibc and Android separately and then tarring the glibc and copying it on Android emulator sdcard and then untarring it on /system folder and then doing chroot on /system/glibc
I compile glibc separately and then place it somewhere in Android source code.
Now while compiling Android source, what should I do so that the entire prebuilt folder structure of glibc gets copied to /system folder and become part of part of system.img.
With this when I copy the system.img to Android emulator and launch it, glibc is already present in /system folder and just need to run the apps in glibc environment.
UPDATE
after I did as per Yuri mentioned in his answer (I created glibc folder and copied everything into it), when I compile the code I get below output.
build/core/main.mk:490: * Some files have been added to ALL_PREBUILT.
build/core/main.mk:491: *
build/core/main.mk:492: * ALL_PREBUILT is a deprecated mechanism that
build/core/main.mk:493: * should not be used for new files.
build/core/main.mk:494: * As an alternative, use PRODUCT_COPY_FILES in
build/core/main.mk:495: * the appropriate product definition.
build/core/main.mk:496: * build/target/product/core.mk is the product
build/core/main.mk:497: * definition used in all products.
build/core/main.mk:498: *
build/core/main.mk:499: * unexpected glibc in ALL_PREBUILT
build/core/main.mk:500: *
build/core/main.mk:501: * ALL_PREBUILT contains unexpected files. Stop.
So I added glibc in build/core/legacy_prebuilts.mk
But then I get
make: * No rule to make target mkdir', needed byout/target/product/generic/root/glibc'. Stop.
Finally I did it in a very unusual way.
I had 3 options:
Use BUILD_PREBUILT variable, but drawback it you can do it for a
single file, but I had multiple files and in a particular forlder
structure
Use PRODUCT_COPY_FILES. But somehow it was not working for me
PRODUCT_COPY_FILES is for a device, and it was not a new device for
me. I was working on emulator.
Using the solution given by Yuri, using ALL_PREBUILT +=, but as Yuri
mentioned it was for GB and I am using JB and ICS and hence was not
working for me.
The approach i took is to use shell script within the Android.mk file.
I used some like this:
Assume you have a folder named my_folder containing entire prebuilt folder structure which needs to be copied to anddroid out folder as is, inside my_folder, I created Android.mk and entered below text:
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
$(shell mkdir -p $(TARGET_OUT)/my_folder/)
$(shell cp -rf $(LOCAL_PATH)/* `pwd`/$(TARGET_OUT)/my_folder/)
This way all my prebuilt set of files and folders in my_folder directory were copied as is to system folder in android out.
I hope this helps someone.
PRODUCT_COPY_FILES must be placed in product mk files (device/mydevice/..), not module files (Android.mk). This is mentioned here.
This format is used for copying dirs:
PRODUCT_COPY_FILES += $(call find-copy-subdir-files,*,vendor/mydir,system/app)
This command is not working for apk files though, giving error:
build/core/Makefile: *** Prebuilt apk found in PRODUCT_COPY_FILES: vendor/mydir/ray-system-ui-release.apk:system/app/ui-release.apk, use BUILD_PREBUILT instead!. Stop.
Here is an example from the book "Embedded Android" that will help you. Create a folder in the root of your aosp project called rootfs-glibc, put there the code that you want to copy, and create there Android.mk file with the following content:
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
# This part is a hack, we're doing "addprefix" because if we don't,
# this dependency will be stripped out by the build system
GLIBC_ROOTFS := $(addprefix $(TARGET_ROOT_OUT)/, rootfs-glibc)
$(GLIBC_ROOTFS): mkdir -p $(TARGET_ROOT_OUT) cp -af $(TOPDIR)rootfs-glibc/* $(TARGET_ROOT_OUT) rm
# The last command just gets rid of this very .mk since it's copied as-is
ALL_PREBUILT += $(GLIBC_ROOTFS)
There is a note that this is true for Gingerbread. Maybe in newer versions of Android the make system has been changed.
Consider using a PHONY_PACKAGE with a custom installation step.
Unlike the $(shell cp whatever) answer above, this will only run during the installation step, rather than on every Make step (which is certainly not what you want).
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := some_module
LOCAL_ADDITIONAL_DEPENDENCIES := FORCE # Decide if you need this
LOCAL_POST_INSTALL_CMD = cd $(LOCAL_PATH) && cp -a mystuff $(TARGET_OUT_WHATEVER)
include $(BUILD_PHONY_PACKAGE)
I was thinking if I could do this way
1. I have both android and glibc compiled separetely.
2. Once both are compiled, I manually copy the glibc entire folder to /out/target/product/generic/system/glibc/ folder
3. Then I run "make snod"
Would that work?
I am developing an Android app on windows, using eclipse.
I would like to use OpenSSL for my Android application. It needs to be used with C++ via NDK.
I tried to download fries' OpenSSL source code from https://github.com/fries/android-external-openssl and build it.
I read the README.android file, but I didn't understand what these instructions are for.
Do I need to download the OpenSSL source code in addition to the fries source code?
I have tried putting all the files from Fries' into my jni folder of the Android project. It complained about not finding e_os.h and openssl/crypto.h and others like that.
More specifically:
In file included from D:/Projects/Fatal/Android/OpenSSL/jni/ssl/s2_meth.c:59:
D:/Projects/Fatal/Android/OpenSSL/jni/ssl/ssl_locl.h:124:18: error: e_os.h: No such file or directory
D:/Projects/Fatal/Android/OpenSSL/jni/ssl/ssl_locl.h:126:28: error: openssl/buffer.h: No such file or directory
D:/Projects/Fatal/Android/OpenSSL/jni/ssl/ssl_locl.h:127:26: error: openssl/comp.h: No such file or directory
I am not sure why it doesn't find those files, I tried to add all sort of paths into LOCAL_C_INCLUDES in all sort of Android.mk files, but nothing worked.
I would like to know how to build OpenSSL for Android. Thank you.
I know this is old, but I kept coming across this when I was searching for this problem. In the case that you are building a standalone OpenSSL to go with your project and are getting this error, I found a solution as per this thread:
In openssl-android/crypto, openssl-android/ssl, and openssl-android/apps, you'll find a variable declaration for local_c_includes that is something like this:
local_c_includes := \
$(NDK_PROJECT_PATH) \
$(NDK_PROJECT_PATH)/crypto/asn1 \
$(NDK_PROJECT_PATH)/crypto/evp \
$(NDK_PROJECT_PATH)/include \
$(NDK_PROJECT_PATH)/include/openssl
If you've placed your openssl-android directory in your Android project in the project/jni directory, then these variables no longer point to the correct location. The way I solved it was to modify these paths to be relative to LOCAL_PATH:
local_c_includes := \
$(LOCAL_PATH)/.. \
$(LOCAL_PATH)/asn1 \
$(LOCAL_PATH)/evp \
$(LOCAL_PATH)/../include \
$(LOCAL_PATH)/../include/openssl
Remember, you'll have to do this for each of the directories you're trying to build (crypto, ssl, or apps).
I realized that the fries' github is just something to patch the source of OpenSSL, it's not a stand alone OpenSSL for android.
It is required because it provide Android.mk files which are required by ndk-build of ndk. You don't want to build it using standard gcc because you want to build it for Android.