I am trying to build my code for h.264 video decoding using hardware decoder(OMX codec) in native code of android 4.0.4 by keeping it in the android source tree. The android source is already built. I am using mm command to build my decoder module.
But when I try to build it I am getting the following error
prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld:
out/target/product/generic/obj/SHARED_LIBRARIES/custom_decoder_intermediates/custom_decoder.o:
in function custom_decoder::decode_video():frameworks/base/include/utils/RefBase.h:171:
error: undefined reference to 'android_atomic_dec'
when I explored about it, came to know that android_atomic_dec is defined in cutils/atomic.h
which is in system/core/libcutils and the header at system/core/include/cutils of AOSP 4.0.4.
So I have added this also in my android.mk via LOCAL_C_INCLUDES but still to get the same error.
Can someone help me to solve this ??....
You must add cutils to the linkage stage:
LOCAL_LDLIBS += -L $(path-to-system-libs) -lcutils
If you are building AOSP tree, use instead the following:
LOCAL_SHARED_LIBRARIES += libcutils
Related
I want to use andengine in my android studio project but I have ndk error while building.
Error:Execution failed for task ':andEngine:compileReleaseNdk'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
D:\Android\android-ndk-r9d\ndk-build.cmd NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\Android.mk APP_PLATFORM=android-19 NDK_OUT=D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\obj NDK_LIBS_OUT=D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\lib APP_ABI=all
Error Code:
2
Output:
D:/Android/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\obj/local/armeabi-v7a/objs/andengine_shared/D_\Android\workspace\simpleclock\simple_clock_as\andEngine\src\main\jni\src\GLES20Fix.o: in function Java_org_andengine_opengl_GLES20Fix_glVertexAttribPointer:GLES20Fix.c(.text.Java_org_andengine_opengl_GLES20Fix_glVertexAttribPointer+0x40): error: undefined reference to 'glVertexAttribPointer'
D:/Android/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\obj/local/armeabi-v7a/objs/andengine_shared/D_\Android\workspace\simpleclock\simple_clock_as\andEngine\src\main\jni\src\GLES20Fix.o: in function Java_org_andengine_opengl_GLES20Fix_glDrawElements:GLES20Fix.c(.text.Java_org_andengine_opengl_GLES20Fix_glDrawElements+0x30): error: undefined reference to 'glDrawElements'
collect2: ld returned 1 exit status
make.exe: *** [D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\obj/local/armeabi-v7a/libandengine_shared.so] Error 1
I suppose I'm missing some OpenGL files?
The Android Gradle plugin's NDK task does not actually use any Android.mk file that you may have provided in your jni/ folder. This was a great source of confusion for me until I figured that out.
It generates a intermediate Android.mk file during the build, based on parameters that you have set in your Gradle build script and on the content of your jni/ folder.
You can see this for yourself by inspecting the source for its NdkCompile task at https://android.googlesource.com/platform/tools/base/+/55aebda607efcc29b8d9d5e1a99d446e320ff288/build-system/gradle/src/main/groovy/com/android/build/gradle/tasks/NdkCompile.groovy.
Note the writeMakeFile(...) method on line 126.
This is why the error you are getting from the ndk-build command that runs as part of your Gradle build references the build script APP_BUILD_SCRIPT=D:\Android\workspace\simpleclock\simple_clock_as\andEngine\build\intermediates\ndk\release\Android.mk, not something like APP_BUILD_SCRIPT=D:\Android\workspace\simpleclock\simple_clock_as\andEngine\src\main\jni\Android.mk as you might expect and want it to.
There is no way of getting the Android Gradle plugin's NDK task to use your own Android.mk file (believe me if there was I would have found it!).
You have two options for getting your NDK code compiling as part of Gradle:
Figure out the correct configuration to put in your build.gradle so that the generated Android.mk file contains the required LOCAL_LDLIBS := -lGLESv2 line and any of the other lines from https://github.com/nicolasgramlich/AndEngine/blob/GLES2/jni/Android.mk that are required.
Write a custom NDK compile task that uses the AndEnginge's Android.mk file directly. I've recently had to do this myself for an NDK source set that requires more parameters than the Android Gradle plugin currently supports passing via Gradle, so it if comes to this I can provide help.
I think in this case option 1 is open and so of course the preferable solution.
Something like this added to the android defaultConfig block should work:
android {
defaultConfig {
ndk {
moduleName "myNDKModule"
stl "stlport_shared"
ldLibs "lGLESv2"
cFlags "-Werror"
}
}
}
Unfortunately I am very much not a C/native code expert (I know practically nothing) so cannot guess whether AndEngine needs LOCAL_MODULE_FILENAME and LOCAL_EXPORT_C_INCLUDES to be set to build correctly. If it does, you'll need to go with approach 2 (at least until if/when the Android Gradle NDK task supports configuring them). Though I have just checked out the AndEngine git repo and successfully run ndk-build after having removed them from its Android.mk file, which is promising.
(I found which NDK properties can be parametrised via inspection of https://android.googlesource.com/platform/tools/base/+/55aebda607efcc29b8d9d5e1a99d446e320ff288/build-system/gradle/src/main/groovy/com/android/build/gradle/internal/dsl/NdkConfigDsl.java).
I had a similar issue, and this video https://www.youtube.com/watch?v=0-rYK2oh8oo helped me to fix the build issues. Basically, you need to download (and extract) NDK from here: http://developer.android.com/ndk/downloads/index.html and specify the NDK location in Module Settings. Also, you need to alter the andEngine's build.gradle file to include
sourceSets{
main{
jni.srcDirs = []
}
}
Android.mk actually includes the line?
https://github.com/nicolasgramlich/AndEngine/blob/GLES2/jni/Android.mk#L10
LOCAL_LDLIBS := -lGLESv2
These errors indicate it.
error: undefined reference to 'glVertexAttribPointer'
error: undefined reference to 'glDrawElements'
When I build as static library, the source code builds well in Android JellyBean 4.1.2 using the mm command. But when I try to build the opencv folder under android/external/opencv as static library, with the following changes in android/external/opencv/Android.mk
+ LOCAL_SHARED_LIBRARIES+= libdl
and
- include $(BUILD_STATIC_LIBRARY)
+ include $(BUILD_SHARED_LIBRARY)
- LOCAL_STATIC_LIBRARIES := libcxcore libcv libcvaux libcvml libcvhighgui
+ LOCAL_SHARED_LIBRARIES := libcxcore libcv libcvaux libcvml libcvhighgui
I get the following error:
android/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/bin/ld: internal error in thumb_branch_common, at /tmp/android-8532/src/build/../binutils/binutils-2.21/gold/arm.cc:4148
collect2: ld returned 1 exit status
make: *** [out/target/product/mydevice/obj/SHARED_LIBRARIES/libcxcore_intermediates/LINKED/libcxcore.so] Error 1
Any idea on how to fix this error?
Thanks in advance.
Regards,
Jai
,,, arm-linux-androideabi/bin/ld: internal error in thumb_branch_common,
at /tmp/android-8532/src/build/../binutils/binutils-2.21/gold/arm.cc:4148
collect2: ld returned 1 exit status
Any idea on how to fix this error?
In Binutils, file arm.cc, Line 4148 there was an Internal Error (in Binutils).
Try newer Binutils (or older) or fix the Bug and submit the Patch.
You can also switch to a different Toolchain (using a different Binutils) and
try that. Sometimes Compiler switches will alter the operation enough to avoid
the Bug.
There is a CHANCE that simply altering the order of the Function in the Source File
of the Code you are compiling (NOT gold/arm.cc, that is where the Compiler Bug is,
change YOUR Source) and that Binutils will read the newly ordered Code differently
and thus avoid the Binutils Bug.
It is also possible that the Code you are linking (the .o Files) was corrupted
either on Disk or by a Bug in the Compiler, or that it is for the wrong endian
(etc.) and that is not being detected.
PS: Thumb-2 Code (in the Compiler's Toolchain) is not Bug free (as you noticed).
See here for some People working on a fix:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gold&id=b72f3238ad32ab420306a0226d8c2e57c52ddf45
... and this is what they came up with:
http://sourceware.org/bugzilla/attachment.cgi?id=6284&action=diff
I think this problem started when upgrading to the Juno Eclipse. I believe the C/C++ build environment was probably upgraded as well at the same time. The NDK was not upgraded.
We have a large mass of C code that compiles under several platforms. We are using the crystax-ndk (r6) to compile our C++ code. To know when we are compiling for Android, we have defined the following in the Android.mk
LOCAL_CFLAGS := -DANDROID_NDK \
-DDISABLE_IMPORTGL \
...
Then in some files we will include different headers depending upon the platform
#ifdef ANDROID_NDK
...
Our code compiles just fine and seems to run fine. However, when opening certain files the C/C++ code analyzer will find many errors. This appears to be because the analyzer doesn't know about the ANDROID_NDK defined variable.
Any idea why the code analyzer is not using the same #defines as the compiler? The code is almost uneditable with all the bogus errors the analyzer is reporting.
I saw you're comment about the analyzer you were refering to.
Eclipse CDT (C/C++ Development Toolkit) does not support parsing Android.mk yet neither does the NDK plugin add that functionality at the time of writing this.
Possible (ugly/annoying) workaround: Set up a header file setting the defines you are missing and include that header file to all files.
Use LOCAL_CPPFLAGS for C++ files and LOCAL_CFLAGS for C files in your Android.mk
Over the last few days I've been having a difficult time trying to build avahi into a static or shared library for use with an existing Android NDK project.
We have a few games in the App and Play stores and my task is to get multiplayer working in the Android versions.
Specifically the task involves replacing the Bonjour component so that these games can connect to each other via zeroconf.
Research seemed to indicate that avahi is the lib that we're looking for, but at this point I'm open to anything that will work!
I'm hoping that someone here can either help me get avahi compiling or suggest another more appropriate (and easier to install) lib.
Project uses android-ndk-r8b and is being built on OSX 10.7.4 using command line (not eclipse)
Got the latest Avahi source from here:
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/avahi.html
homebrewed all the necessary libs to get ./configure to run without errors.
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --disable-static --disable-mono --disable-monodoc --disable-gdbm --disable-libdaemon --disable-nls --disable-gtk --disable-gtk3 --disable-python --disable-qt3 --disable-qt4 --enable-core-docs --with-distro=none
./configure runs with no apparent red flags.
make results in this compile error:
socket.c: In function 'ipv6_pktinfo':
socket.c:271: warning: unused variable 'yes' [-Wunused-variable]
socket.c:270: warning: unused parameter 'fd' [-Wunused-parameter]
socket.c: In function 'avahi_send_dns_packet_ipv6':
socket.c:609: error: 'IPV6_PKTINFO' undeclared (first use in this function)
socket.c:609: error: (Each undeclared identifier is reported only once
socket.c:609: error: for each function it appears in.)
socket.c: In function 'avahi_recv_dns_packet_ipv6':
socket.c:869: error: 'IPV6_HOPLIMIT' undeclared (first use in this function)
socket.c:878: error: 'IPV6_PKTINFO' undeclared (first use in this function)
make[2]: *** [libavahi_core_la-socket.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Figured that it's not building against the android-ndk-r8b libs or finding ipv6.h or something.
Checked my .bash_profile.sh file:
export PATH=/Users/Muy01/Projects/Development/Android/android-sdks/tools/:$PATH
export PATH=/Users/Muy01/Projects/Development/Android/android-sdks/platform-tools/:$PATH
export PATH=/Users/Muy01/Projects/Development/Android/android-ndk-r8b/:$PATH
added --host=arm-linux-androideabi to the ./configure arguments list
resulting in this error:
checking host system type... Invalid configuration `arm-linux-androideabi': system `androideabi' not recognized
Couldn't figure out how to get a list of available host system types so changed direction and decided to try and build the static lib via Android.mk file.
Found this post on creating an appropriate Android.mk file:
can't compile avahi on android
Realized that I don't have Android.mk files within all the subdirectories.
Researched, downloaded, built, Androgenizer to try and convert all the Makefile.am files into Android.mk files.
http://cgit.collabora.com/git/user/derek/androgenizer.git/
Couldn't figure out or find info on how to do that though =/
Decided to try and create my own Android.mk file:
LOCAL_PATH := $(call my-dir)
ROOT_LOCAL_PATH :=$(call my-dir)
#Build avahi into a static lib
include $(CLEAR_VARS)
AVAHI_TOP := $(ROOT_LOCAL_PATH)/../avahi-0.6.31
MY_SOURCES := $(wildcard $(AVAHI_TOP)/avahi-core/*.c*)
MY_SOURCES += $(wildcard $(AVAHI_TOP)/avahi-common/*.c*)
LOCAL_C_INCLUDES := $(AVAHI_TOP)
LOCAL_SRC_FILES := $(MY_SOURCES:$(LOCAL_PATH)%=%)
LOCAL_MODULE := avahi
include $(BUILD_STATIC_LIBRARY)
Results in compile time errors for avahi-core/iface-linux.c:33:0:
/avahi-0.6.31/avahi-core/iface-linux.h:27:8: Redefinition of 'struct AvahiInterfaceMonitorOSDep'
/avahi-0.6.31/avahi-core/iface.h:46:16: Originally defined here
/avahi-0.6.31/avahi-core/iface-linux.h:33:9: Redeclaration of enumerator 'LIST_IFACE'
/avahi-0.6.31/avahi-core/iface.h:52:9: Previous definition of 'LIST_IFACE' was here
/avahi-0.6.31/avahi-core/iface-linux.h:34:9: Redeclaration of enumerator 'LIST_ADDR'
/avahi-0.6.31/avahi-core/iface.h:53:9: Previous definition of 'LIST_ADDR' was here
/avahi-0.6.31/avahi-core/iface-linux.h:35:9: Redeclaration of enumerator 'LIST_DONE'
/avahi-0.6.31/avahi-core/iface.h:54:9: Previous definition of 'LIST_DONE' was here
/jni//../avahi-0.6.31/avahi-core/iface-linux.c: In function 'netlink_callback':
And now I'm pretty much stuck.
I tried #if 0'ing out the iface-linux.c and h files resulting in a cascading slew of other errors, so prob a bad idea.
Thinking that it may be something I've done wrong with the ./configure command?
Perhaps an issue with my Android.mk file?
I figure this must be something that quite a few developers are dealing with so I'm probably missing something because I can't seem to find any good information via google.
Any help would be much appreciated!
I've sent this out to the avhi mailing list as well, if I get a response there I will post here for posterity.
Thanks,
Chris
I'll follow up here with the solution that worked for me.
My solution was to use JMDNS instead of Avahi.
There's not much traffic on the Avahi mailing list.
JMDNS has working examples available.
JMDNS took me about 4 hours to set up within my NDK environment and about a day to work out some "kinks."
tar avahi-0.6.31
patch -p1 < 0001-Add-Android-support.patch
patch -p1 < 0002-Add-uninstalled.pc.in-files.patch
cd avahi-0.6.31
./configure --sysconfdir=/etc --localstatedir=/var
make
cd the subdirectories: make Android.mk
then, you will see Android.mk in all the subdirectories.
ndk-build V=1 NDK_LOG=2 APP_ABI="armeabi armeabi-v7a"
I think I spent most of yesterday unsuccessfully wrestling with this, any help would greatly appreciated and make me extremely happy! Even a next step to try to find the root of the issue is something I'm stuck on at the moment!
I have an Android 2.2 project that's trying to reference a prebuilt LuaJIT static library but ndk-build gives me this error:
test_android.cpp:25: undefined reference to `luaL_newstate'
I built LuaJIT as liblua.a, I've placed that in the root of my JNI directory with the relevant headers. I've have one Android.mk as shown below:
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := lua
LOCAL_SRC_FILES := liblua.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := test
LOCAL_CFLAGS := -Werror
LOCAL_SRC_FILES := test_android.cpp
LOCAL_LDLIBS := -llog -lGLESv2
LOCAL_STATIC_LIBRARIES := lua
include $(BUILD_SHARED_LIBRARY)
In test_andrdoid.cpp I've got this code:
extern "C"
{
#include "lua.h"
#include "lauxlib.h"
#include "lualib.h"
}
void test()
{
lua_State* lua = lua_open();
}
This seems like a linker error, for some reason the static library file is not being correctly referenced. But, to me, the makefile seems correct.
Any help would be greatly appreciated!
To start with: is there anyway to see how everything is being linked
together and if my shared library module is really get access
to the static library?
Additional Information
Here's extra information that I think could be relevant!
Building the library
Maybe it's the static lib file that's not correct? (Is there anywhere I could download a prebuilt one to check?). I made it with this script (from the LuaJIT website). I'm using the latest stable LuaJIT, 1.1.8
NDK=/cygdrive/c/android-ndk-r8b
NDKABI=8
NDKVER=$NDK/toolchains/arm-linux-androideabi-4.4.3
NDKP=$NDKVER/prebuilt/linux-x86/bin/arm-linux-androideabi-
NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
make linux HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF"
This builds fine and creates a liblua.a in the /src/ directory. (I ran nm on it and it lists out all the function prototypes I'd expect). I don't know if there's anything else I can do to ensure it's really a build for ARM?
NDKABI=8 means I'm targeting Android 2.2
Setting up the test Android Project
I create a brand new 2.2 android project using this command:
android create project --target 3 --name test --path . --activity TestActivity --package com.test
Target 3 maps to Android 2.2 on my system (using android list devices).
I create the jni folder and have a test_android.h and test_android.cpp. Then I use ndk-build to build them - which works fine when I'm not trying to reference LuaJIT. When I do try and use Lua I get the following error:
Full Error Message
Cygwin : Generating dependency file converter script
Compile++ thumb : test <= test_android.cpp
In file included from jni/test_android.h:3:0, from jni/test_android.cpp:2:
C:/android-ndk-r8b/platforms/android-8/arch-arm/usr/include/jni.h:592:13: note:
the mangling of 'va_list' has changed in GCC 4.4
Prebuilt : liblua.a <= jni/
StaticLibrary : libstdc++.a
SharedLibrary : libtest.so
obj/local/armeabi/objs/test/test_android.o: In function `test()':
C:\Users\Grrr\Documents\mycode\static_lib_test/jni/test_android.cpp:25: undefined reference to `luaL_newstate'
collect2: ld returned 1 exit status
/cygdrive/c/android-ndk-r8b/build/core/build-binary.mk:378: recipe for target `obj/local/armeabi/libtest.so' failed make: *** [obj/local/armeabi/libtest.so] Error 1
Most of the issues I've seen searching around are due to the local library include order, as I only have one library this shouldn't be an issue and suggests I've managed to get something more fundamental wrong :)
Update
I've since built normal Lua and added that as prebuilt static library and it works fine. I suspect its how I've built LuaJIT but I'm not sure how to correctly build it, or find a working prebuilt version.
The linking for this was fine, or at least the makefile was.
The problem was the LuaJIT library wasn't built for ARM (I used objdump -a lualib.a, to check this). I downloaded the latest LuaJIT, ran the script under linux and got an ARM library. Everything links nicely now!