Problems compiling avahi into Android NDK project - android

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"

Related

ndk_build.cmd in cygwin not recognizing included mk files

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.

Hello-Jni on Windows, Android NDK - build-local.mk: No such file

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.

Android OpenCV shared library build error

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

Linker trouble when using LuaJIT prebuilt static library with android under cygwin

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!

cannot find -lgnustl_static: Compiling Android SDL port with NDK r7

I'm trying to build this port of libSDL for Android, using the new Android NDK r7 release:
https://github.com/pelya/commandergenius
I know I am doing some things to some degree "unsupported": I am using cygwin&windows despite that being mentioned in the README as no longer being supported. That being said, I can hack out shell scripts and solve my problems as necessary and have it compiling but not linking.
So anyways I have compiling working until the linking (sorry for large block, relevant part trimmed below):
/cygdrive/c/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-ar crs obj/local/armeabi/libflac.a ./obj/local/armeabi/objs-debug/flac/src/ogg_decoder_aspect.o ./obj/local/armeabi/objs-debug/flac/src/md5.o ./obj/local/armeabi/objs-debug/flac/src/stream_decoder.o ./obj/local/armeabi/objs-debug/flac/src/fixed.o ./obj/local/armeabi/objs-debug/flac/src/memory.o ./obj/local/armeabi/objs-debug/flac/src/stream_encoder.o ./obj/local/armeabi/objs-debug/flac/src/window.o ./obj/local/armeabi/objs-debug/flac/src/cpu.o ./obj/local/armeabi/objs-debug/flac/src/ogg_encoder_aspect.o ./obj/local/armeabi/objs-debug/flac/src/lpc.o ./obj/local/armeabi/objs-debug/flac/src/float.o ./obj/local/armeabi/objs-debug/flac/src/bitmath.o ./obj/local/armeabi/objs-debug/flac/src/metadata_object.o ./obj/local/armeabi/objs-debug/flac/src/ogg_helper.o ./obj/local/armeabi/objs-debug/flac/src/metadata_iterators.o ./obj/local/armeabi/objs-debug/flac/src/bitreader.o ./obj/local/armeabi/objs-debug/flac/src/bitwriter.o ./obj/local/armeabi/objs-debug/flac/src/stream_encoder_framing.o ./obj/local/armeabi/objs-debug/flac/src/crc.o ./obj/local/armeabi/objs-debug/flac/src/format.o ./obj/local/armeabi/objs-debug/flac/src/ogg_mapping.o
C:/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld.exe: cannot find -lgnustl_static
collect2: ld returned 1 exit status
/cygdrive/c/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-ar crs obj/local/armeabi-v7a/libflac.a ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_decoder_aspect.o ./obj/local/armeabi-v7a/objs-debug/flac/src/md5.o ./obj/local/armeabi-v7a/objs-debug/flac/src/stream_decoder.o ./obj/local/armeabi-v7a/objs-debug/flac/src/fixed.o ./obj/local/armeabi-v7a/objs-debug/flac/src/memory.o ./obj/local/armeabi-v7a/objs-debug/flac/src/stream_encoder.o ./obj/local/armeabi-v7a/objs-debug/flac/src/window.o ./obj/local/armeabi-v7a/objs-debug/flac/src/cpu.o ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_encoder_aspect.o ./obj/local/armeabi-v7a/objs-debug/flac/src/lpc.o ./obj/local/armeabi-v7a/objs-debug/flac/src/float.o ./obj/local/armeabi-v7a/objs-debug/flac/src/bitmath.o ./obj/local/armeabi-v7a/objs-debug/flac/src/metadata_object.o ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_helper.o ./obj/local/armeabi-v7a/objs-debug/flac/src/metadata_iterators.o ./obj/local/armeabi-v7a/objs-debug/flac/src/bitreader.o ./obj/local/armeabi-v7a/objs-debug/flac/src/bitwriter.o ./obj/local/armeabi-v7a/objs-debug/flac/src/stream_encoder_framing.o ./obj/local/armeabi-v7a/objs-debug/flac/src/crc.o ./obj/local/armeabi-v7a/objs-debug/flac/src/format.o ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_mapping.o
C:/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld.exe: cannot find -lgnustl_static
collect2: ld returned 1 exit status
Relevant failure, if you can't parse that wall of text:
ld.exe: cannot find -lgnustl_static
Now, if I look at the Windows NDK release I find gnustl_* files here:
under ./android-ndk-r7/sources:
./cxx-stl/gnu-libstdc++/libs/armeabi/libgnustl_shared.so
./cxx-stl/gnu-libstdc++/libs/armeabi/libgnustl_static.a
./cxx-stl/gnu-libstdc++/libs/armeabi-v7a/libgnustl_shared.so
./cxx-stl/gnu-libstdc++/libs/armeabi-v7a/libgnustl_static.a
./cxx-stl/gnu-libstdc++/libs/x86/libgnustl_shared.so
./cxx-stl/gnu-libstdc++/libs/x86/libgnustl_static.a
I looked also at the linux android NDK distribution and they are packaged the same (only have libgnustl files, built, under the sources directory).
So I have 3 questions:
why would we be using -l to link libgnustl_static when it's a .a
file? Shouldn't that be just including the .a file in the object
list, or alternately be -lgnustl_shared?
why are these files only under "sources"? I would have expected them to be in the "toolchains" library NDK directory. How does anyone ever link against libgnustl?
Can I copy these files somewhere where they'll be seen by the linker? Just adding their directory with -L hasn't seemed to work, and plus I need to get the right versions linked with the right build target (armeabi vs armeabi-v7 vs x86)
This is a bug in gcc/NDK that manifests itself slightly different on Linux, Cygwin, and Windows (non Cygwin).
Here's what I did to fix it (works for Linux and for one of my developers who is blind and has to use Cygwin)...
Remove the line that says, APP_STL := gnustl_static from your Application.mk (it's broken in the NDK, and it's broken slightly differently on Linux Cygwin, Windows)
add a line to $(LOCAL_LDLIBS) in your Android.mk file that says:
$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi-v7a/libgnustl_static.a
also add two lines to Android.mk that say:
LOCAL_C_INCLUDES := $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/include
LOCAL_C_INCLUDES += $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi-v7a/include
The foregoing will accomplish what having, APP_STL := gnustl_static in your Application.mk was supposed to.
In case this plagues anyone else, the solution is to remove -lgnustl_static and instead list
c:\path\to\armeabi\libs\libgnustl_static.a in the linker command.
Do not use /cygdrive style path, as the linker will fail to find the file. Use actual c:\...

Categories

Resources