I'm trying to use Google's Protocol buffer on a C++ project. I can build it just fine for say... an iOS framework target. However, I can't seem to get the compiler to find any of the google/protobuf files. I already have the static library file (not sure if this one works on my architecture? i used: https://gist.github.com/BennettSmith/9487468ae3375d0db0cc)
in the output of the proto file, let's say blah.pb.h, i have a reference to protobuf:
#include <google/protobuf/stubs/common.h>
the compiler can't find that ^ reference.
I've tried to ndk-build with something like this:
include $(CLEAR_VARS)
LOCAL_MODULE := libprotobuf
LOCAL_SRC_FILES := src/lib/libprotobuf.a
include $(PREBUILT_STATIC_LIBRARY)
LOCAL_SRC_FILES:=$(shell find src/lib -name '*.cpp')
LOCAL_MODULE := mymodule
LOCAL_C_INCLUDES += ./src/lib
LOCAL_STATIC_LIBRARIES := libprotobuf
include $(BUILD_SHARED_LIBRARY)
but it doesn't seem to help at all. what's going on? how do i include lib protobuf when i have the .a file? do i have to compile it from source?
turns out i have to multiple things:
i have to duplicate the entire protobuf include folder (the one with all the headers) to my project. and then include them in my LOCAL_EXPORT_C_INCLUDES
also, the command that i was using to do ndk-build is also not fully correct. it was missing a ton of stl stuff, like missing "string" or vector or map. so i used this instead:
ndk-build V=1 NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=Android.mk APP_STL=stlport_static
NDK - Android Java with native (JNI) C++ code build issue
Related
I have an NDK project where I build the shared libraries using the cross-compiler and standard gnu make utils. That is done with a separate script. But for the purpose of using the libraries in my project, I would like my Android.mk process to call my script to generate the shared library if it hasn't already been built, and then have Android.mk wrap it using the PREBUILT_SHARED_LIBRARY process.
Currently, if I run my script offline to generate libmy_so.so, then the following makefile will work. However, if I don't run the script explicitly first, I get the following error:
Android NDK: ERROR:/path_to_project/Android.mk:my_module: LOCAL_SRC_FILES points to a missing file
and my script is never called, so the make process is failing before even trying to resolve the dependency.
include $(CLEAR_VARS)
LOCAL_MODULE := my_module
LOCAL_SRC_FILES := libmy_so.so
LOCAL_EXPORT_CFLAGS := # some stuff
LOCAL_EXPORT_LDLIBS := # some stuff
$(LOCAL_PATH)/libmy_so.so:
echo "generate file"
$(shell run_script_that_creates_libmy_so.so)
include $(PREBUILT_SHARED_LIBRARY)
Is there a clean solution to this? I am even ok with running the script automatically as a preprocessing step (I can always have my script quietly exit if the file exists already), but I have not found an incantation that allows the LOCAL_SRC_FILES variable to point to a non-existent file. I have considered placing a dummy libmy_so.so to start, but that is an ugly hack.
Found a hack -- better way?
I found a hack. The makefile prebuilt-library.mk in the NDK contains the following lines:
ifndef prebuilt
$(call __ndk_info,ERROR:$(LOCAL_MAKEFILE):$(LOCAL_MODULE): LOCAL_SRC_FILES points to a missing file)
$(call __ndk_info,Check that $(prebuilt_path) exists, or that its path is correct)
$(call __ndk_error,Aborting)
#endif
I created a copy of this file (and prebuilt-shared-library.mk to which I reference my copy of prebuilt-library.mk) and commented those lines out to stop the error. Then the trick is to make some target that is evaluated first depend on the file I want to generate. After digging through the .mk scripts in the NDK, I found that libraries serves the purpose. By adding libraries: $(LOCAL_PATH)/libmy_so.so to Android.mk, it will finally do what I want.
include $(CLEAR_VARS)
LOCAL_MODULE := my_module
LOCAL_SRC_FILES := libmy_so.so
LOCAL_EXPORT_CFLAGS := # some stuff
LOCAL_EXPORT_LDLIBS := # some stuff
$(LOCAL_PATH)/libmy_so.so:
echo "generate file"
$(shell run_script_that_creates_libmy_so.so)
libraries: $(LOCAL_PATH)/libmy_so.so
include /path/to/my/mk/files/prebuilt-shared-library.mk
This is obviously less than ideal as I would like to make sure my makefiles mature with newer versions of the NDK, but it does the trick. Still interested in more elegant solutions.
I've looked around at some questions about writing android.mk files and the "make: * No rule to make target .c needed by .o"** they all center around typos which I don't think that I have.
This is an SDL project that builds fine with my CMake build scripts but I just can't get android.mk to work for me.
Here's the project setup in cmake
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(blp)
#set(CMAKE_MACOSX_RPATH 1)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake_modules)
FIND_PACKAGE(SDL2 REQUIRED)
INCLUDE_DIRECTORIES(${SDL2_INCLUDE_DIR})
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/core_math")
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/utils/time_utils")
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/utils/resource_utils")
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/ren_opengl")
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/core_engine")
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/components/renderable2d")
INCLUDE_DIRECTORIES("${PROJECT_SOURCE_DIR}/source/glm/vec3.hpp")
FIND_PACKAGE(SDL2 REQUIRED)
INCLUDE_DIRECTORIES(${SDL2_INCLUDE_DIR})
FIND_PACKAGE(SDL2_IMAGE)
INCLUDE_DIRECTORIES(${SDL2_IMAGE_INCLUDE_DIR})
ADD_SUBDIRECTORY(source)
ADD_SUBDIRECTORY(project)
SET(SRC_FILES main.c)
SET(EXTERNAL_TARGET_LIBS ${SDL2_LIBRARY} ${SDL2_IMAGE_LIBRARY})
SET(COMPONENTS renderable2d)
SET(INTERNAL_TARGET_LIBS core_math time_utils resource_utils ren_opengl)
SET(TARGET_LIBS ${INTERNAL_TARGET_LIBS} ${EXTERNAL_TARGET_LIBS} ${COMPONENTS})
FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/)
the project subfolder is where I can create different projects and reuse the source dynamic libs that I create.
inside the source, you can see I have a bunch of dynamic libs that are created. At the end there's the dynamic libs and one .h and .c class that imports all of them, then I import that one .h file inside my project to use the libs.
Now onto my android.mk file, it's not very complete yet but this is where I am running into trouble.
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := main
SDL_PATH := ../SDL
LOCAL_C_INCLUDES := $(LOCAL_PATH)/$(SDL_PATH)/include/
LOCAL_C_INCLUDES += $(LOCAL_PATH)/src/utils/time_utils/
# Add your application source files here...
LOCAL_SRC_FILES := $(SDL_PATH)/src/main/android/SDL_android_main.c \
utils/time_utils.c \
//removing the above line, core_engine.c throws an import error
//adding the above line I get the error listed at the bottom
core_engine/core_engine.c \
project.c
LOCAL_SHARED_LIBRARIES := SDL2
LOCAL_LDLIBS := -lGLESv1_CM -lGLESv2 -llog
include $(BUILD_SHARED_LIBRARY)
make: *** No rule to make target `/Users/blubee/SDL/android-project/jni/src/time_utils/time_utils.c', needed by `/Users/blubee/SDL/android-project/obj/local/armeabi/objs/main/time_utils/time_utils.o'. Stop.
each lib is under it's own folder int he project source tree like this
source/components/renderable2d/renderable2d.c /.h
source/core_engine/core_engine.c /.h
source/core_math/mat4_scalar/mat4_scalar.c /.h
source/core_math/vec3_scalar/vec3_scalar.c /.h
source/..
etc...
It could be a build oder or the order in which I am defining the sources files in the android.mk folder, I am not sure. Any suggestions? I also made sure that there's no typos or extra spaces in my environment variables or the source file for the android.mk
It seems that android.mk is a lot more sensitive to header include order more so than cmake.
I simplified my project just to a main.c with a #include "SDL.h" and that builds just fine.
I will go from there and learn android.mk, while it's similar to cmake it's a lot more picky.
I have a series of existing libraries which I need to re-use in an Android application. The layout is similar to:
\Libraries\libOne
\Libraries\libTwo [Static library]
\Libraries\libThree
\Applications\MyApplication\ [Application]
libTwo depends on libOne, and libThree depends on libTwo. How can I get the build system to build all of the libraries in the correct order? I'm trying to use Eclipse, but if necessary I can use the command line.
All of these libraries will eventually be referenced by a Java application (and use JNI to interact with them). Any clues on how I setup the Android.mk / Application.mk files?
I've tried using BUILD_STATIC_LIBRARY for libTwo, but it doesn't actually output any files! I was expecting a libTwo.a file, but nothing gets compiled or built.
Do I write one Android.mk in the application? Or an Android.mk for each project?
OK, now I see your edit, and this makes it possible to answer the specific question.
You must have at least one Android.mk file for your application if you want to use Android NDK to build your native library/ies. This is not a requirement, though. It is OK to build it though Cmake, or a "standalone toolchain" with "traditional" makefiles, or with a MS Visual Studio plugin, or any other way. It is the result that matters. The result is a shared object built with a compatible compiler for a bionic runtime.
It makes goode sense to put the library in ${project_root}/libs/armeabi/ directory (for ARM v6 compatible devices, other subdirectories for x86, MIPS, arm v7a) to allow the APK builder pack it correctly, to allow app installer to unpack the correct version (compatible with the device processor) into /data/data/${package_name}/lib directory on the device, and finally to be able to use System.loadLibrary(short_name) to use it from Java. But it is also quite possible to pack the so file differently, unpack it manually, and load it from any place on the device file system (provided your app has permission to write and read this file).
But if we filter out exotic cases, it is much more comfortable to have an Android.mk in the ${project_root}/jni directory. In terms of ndk-build command, each library is a separate MODULE, but all three may be defined in one Android.mk file. On the other hand, if your libraries are isolated (e.g. come from separate 3rd parties), you will probably prefer to create three Android.mk files. Luckily, ndk-build is nothing but a wrapper around gnu make, and the simple include statement in Android.mk works as in any other makefiles.
In summary, your case is probably covered by a simple Applications/MyApplication/ [Application]/jni/Android.mk file:
include ../../Libraries/libOne/Android.mk
include ../../Libraries/libTwo/Android.mk
include ../../Libraries/libThree/Android.mk
I don't know what dependency you have between libOne and libTwo, but for libOne the file Libraries/libOne/Android.mk will look like
LOCAL_PATH = $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libOne
LOCAL_SRC_FILES := first.c
include $(BUILD_STATIC_LIBRARY)
and Libraries/libThree/Android.mk
LOCAL_PATH = $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libThree
LOCAL_SRC_FILES := third.c
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../libOne $(LOCAL_PATH)/../libTwo
LOCAL_STATIC_LIBRARIES := libOne libTwo
include $(BUILD_SHARED_LIBRARY)
You should run ndk-build from Applications/MyApplication/ [Application] directory - either from command prompt, or through Eclipse ADT plugin.
update the same may be expressed by one Android.mk file in jni directory:
LOCAL_PATH = ../../Libraries/libOne
include $(CLEAR_VARS)
LOCAL_MODULE := libOne
LOCAL_SRC_FILES := first.c
include $(BUILD_STATIC_LIBRARY)
LOCAL_PATH = ../../Libraries/libThree
include $(CLEAR_VARS)
LOCAL_MODULE := libThree
LOCAL_SRC_FILES := third.c
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../libOne $(LOCAL_PATH)/../libTwo
LOCAL_STATIC_LIBRARIES := libOne libTwo
include $(BUILD_SHARED_LIBRARY)
There is an android section in the projects' properties, where you can edit the library dependencies. It can only be used, if libOne libTwo and libThree are marked as libraries, in their properties panel.
I'm trying to create a shared library that links to another shared library.
Here is my main module Android.mk:
TOP_LOCAL_PATH := $(call my-dir)
include $(call all-subdir-makefiles)
LOCAL_PATH := $(TOP_LOCAL_PATH)
include $(CLEAR_VARS)
LOCAL_CPP_EXTENSION := cpp
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include/ $(LOCAL_PATH)/lib/include
LOCAL_MODULE := SightCore-jni
LOCAL_SRC_FILES := SightDemo.cpp SightCore-jni.cpp
LOCAL_SHARED_LIBRARIES := SightAPI
LOCAL_LDLIBS = -llog
include $(BUILD_SHARED_LIBRARY)
I also have the prebuilt shared library in ./lib directory with its own Android.mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := SightAPI
LOCAL_SRC_FILES := libSightAPI.so
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
The SightCore-jni.cpp source file is the jni interface to the shared library and is loaded using the command
System.loadLibrary("SightCore-jni");
During the ndk-build process I get no compilation or linkage errors.
When I try to run the application and access one of the native methods I get the UnsatsfiedLinkError.
I noticed that if disable the references to the SightAPI in my jni code and put a typo to the LOCAL_STATIC_LIBRARIES := SightAPI line, The build is successful and there is no UnsatisfiedLinkError.
This mean that the jni code I have is good (I'm actually sure it is ok...)
So the observation is as follows:
If I compile the shared library with the prebuilt shared library I get a corrupted .so file.
If I compile the same ndk project without linking to the prebuilt shared library there is no problem loading the shared library from the java side.
Please help me out if you can.
Thanks in advance,
Ita
Found the issue.
Apparently the ndk build system doesn't automatically load referenced shared libraries, even if they are declared in your Android.mk.
I had to call on System.loadLibrary(SightAPI) & System.loadLibrary("SightCore-jni") in order to solve this issue. I would have expected that the only library to load would have been the main library SightCore-jni.
Well..I guess the moral is If you want something done, do it yourself :)
+1 to Roy Samuel for his effort and correct instincts.
I hope this helps anyone.
Cheers
Have you made sure that the cpp function name, that you'd like to use over JNI, is corresponding to the package name of the Java wrapper class where System.loadLibrary("SightCore-jni"); is present?
e.g. If you would like to use the C function, myFunction in the java layer, and suppose your JNI wrapper class is in the package com.my.package.sightcore,
then your C code function name should be like this :
JNIEXPORT JNICALL Java_com_my_package_sightcore_myFunction(JNIEnv * env, jobject thiz, ...)
If you are running your app on your device,
See if the API levels, and hence, the sdk release matches to your device's android version (API level).
Hope this helps. Let me know if you need more clarifications...
This happened to me, and the solution for me was to make sure I was including the proper file libgnustl_shared.so and not libc++_shared.so after I switched compilers. So, just making sure either one of these files is the correct one for your build, and making sure it's been updated with the latest, you shouldn't get this issue any longer.
I have written an Android app. It uses a main C-code module and a linked-in C-code module. Now I want to replace the linked-in module with an ARM assembler module. Anyone have a simple example?
Here's an example of Android.mk file that will build sourcetree containing assembly. To see a complete example check the hello-neon sample distributed in the NDK package.
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_ARM_MODE := arm # remove this if you want thumb mode
LOCAL_ARM_NEON := true # remove this if you want armv5 mode
LOCAL_CFLAGS := -std=c99 -pedantic -v
LOCAL_SRC_FILES := # list your C, C++ and assembly sources here.
# assembly source files ends with extension .S
# add .arm after the extension if you want to compile in armv5 mode (default is thumb)
# add .arm.neon to compile in armv7 mode
LOCAL_C_INCLUDES := $(LOCAL_PATH)
LOCAL_LDLIBS := -llog
LOCAL_MODULE := #the name of your shared library
include $(BUILD_SHARED_LIBRARY)
I wrote a tutorial to do exactly this.
http://www.eggwall.com/2011/09/android-arm-assembly-calling-assembly.html
ARM assembly in Android isn't difficult, but there are many moving pieces: you need an assembly source, a C stub, a Makefile, and Java stub "native" methods that call the underlying assembly code.
You could download the source code from the link above, and see how it works. Once you have one working example, it is easy to poke and make it fit your need.
I Saw the article by vikram I have an opinion that for beginners, it is better to build and run assembler code in Android using android source code.
e.g. you can create a module with the specification "BUILD_EXECUTABLE" in the Android.mk
You can have a main function inside the C code and have the assembler code built along with main.c
You can add such a module even under gingebread/frameworks/base/<mymodule>