Android.mk will compile .c source but not .cpp - android

I have an Android.mk file that compiles my NDK C code just fine:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := galib
LOCAL_SRC_FILES := galib.c tables-lr35-contam.c tables-lr35-perf.c
LOCAL_CFLAGS := -DTARGET_ANDROID=1
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_SHARED_LIBRARY)
I'd like to call the first source galib.cpp instead of .c because that's the name I need it to be when compiling it in the WPF environment. It really is just C code but to make a DLL I have to name it .cpp for it to handle the __declspec(dllexport) stuff properly.
However, when I rename it galib.cpp and change the .mk file to say the same and try to build it for Android, I get the error:
$ ndk-build
make: *** No rule to make target `/cygdrive/c/apk/adev/android/etold/jni/galib.c',
...needed by `/cygdrive/c/apk/adev/android/etold/obj/local/armeabi/objs/galib/galib.o'. Stop.
as though it still wants a .c file for some reason. I also tried "ndk-build -B" in case there's something left over from the .c build, but that results in the same error. Any idea why? Thanks!

I know that you asked that long time ago. But anyway - for other people like me:
I tackled into this problem too just now.
For some reason clean build doesn't do the job even when you change the sources list at LOCAL_SRC_FILES.
I had to navigate to \obj\local\armeabi\objs\ within the project and clean .o files manually.
After that it compiled fine.

Related

Android.mk PREBUILT_SHARED_LIBRARY how to generate LOCAL_SRC_FILES file from script?

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.

android.mk sdl building errors

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.

target pattern contains no '%'

I tried to build the ndk and get error
/android-ndk-r9/build/core/prebuilt-library.mk:68: *** target pattern contains no '%'. Stop.****
my Android.mk code is :
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
OPENCV_CAMERA_MODULES := on
OPENCV_INSTALL_MODULES := on
#OPENCV_LIB_TYPE:=SHARED
include D:/Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
LOCAL_SRC_FILES := F_jni.cpp
LOCAL_C_INCLUDES += $(LOCAL_PATH)
LOCAL_LDLIBS += -llog -ldl
LOCAL_MODULE := f
include $(BUILD_SHARED_LIBRARY)
please help Until I resolve my problem.I'm really confused.I tried several ways and I could not solve my issue.
ndk-build invokes make which does not handle the : character in targets well. If your project resides on disk D:, too, then you can refer to OpenCV without the drive letter,
include /Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
Otherwise you can try
include //D/Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
include //localhost/D$/Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
If nothing helps, copy your OpenCV SDK such that you can use a relative path, e.g.
include ../../OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
PS The source of your troubles is probably cygwin somewhere on the PATH. Since November 2011, NDK r7, ndk-build does not need cygwin. OpenCV made the reciprocate step short afterwards. Unfortunately, many developers still need cygwin for their daily work; furthermore, until recently, you still needed cygwin to run ndk-dgb (you have ndk-gdb-py.cmd now!). So my advice is to remove cygwin\bin directory from your PATH before you run ndk-build.cmd. You can easily do it in Project build properties if you use Ecliplse/ADT to build your native code.

How to build NDK Library over a previous build

I'm using the Android NDK to build a library. I had everything working well, but then I needed to change a package name which is referenced in the library. I tried to build the library again once I made the change, by calling ndk-build in its folder, but this is the only output I get and it does not seem to be fully building:
C:\my-app\jni>ndk-build
Install : libfilters.so => libs/armeabi/libfilters.so
This then leads to an unsatisfied link error when I try to run the application. I'll post my .mk file, but I don't think that should matter because my previous library was working with this .mk file. My guess is that there is a problem with me trying to build this one over the previous build. Any suggestions? Here's my .mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := filters
LOCAL_SRC_FILES := filters.cpp
LOCAL_LDLIBS := -lm -llog -ljnigraphics
include $(BUILD_SHARED_LIBRARY)
Thanks for the help.
Edit: Once I do the rebuild as indicated, then I get the following error:
"Compile++ thumb : filters <= filters.cpp
C:/a-fa-outsidelands//jni/filters.cpp:4:28: fatal error: android/bitmap.h: No such file or directory
compilation terminated.
ndk-build -B
forces a full rebuild.

Android NDK, No rule to make target

I've seen this question other places, but the answers don't seem to apply to my situation. I've got a .cpp file (not a .c file). I'm getting the error:
make: * No rule to make target jni/native.c', needed byobj/local/armeabi/objs/native/native.o'. Stop. Cirapi_android C/C++ Problem
Here's my Android.mk file (very simple):
LOCAL_PATH:=$(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS:=-llog
LOCAL_MODULE:=native
LOCAL_SRC_FILES:=native.cpp
include $(BUILD_SHARED_LIBRARY)
I've removed all the extra spaces that solved other's problems. It's complaining about native.c which I don't even have listed in my makefile. Any ideas?
I'm on MacOSX Snow Leopard, Eclipse Juno, NDK r8
Got it to work...not sure what the key was...changed the makefile to..
TOP_LOCAL_PATH:=$(call my-dir)
include $(call all-subdir-makefiles)
LOCAL_PATH := $(TOP_LOCAL_PATH)
include $(CLEAR_VARS)
LOCAL_LDLIBS:=-llog
LOCAL_MODULE:=native
LOCAL_SRC_FILES:=native.cpp
include $(BUILD_SHARED_LIBRARY)
...also removed the .o files from the obj directory...suspected that a clean was not working correctly.

Categories

Resources