I have been building a shared library with the Android NDK and now want to build it as a static library. I assumed that all I had to do was change BUILD_SHARED_LIBRARY to BUILD_STATIC_LIBRARY in Android.mk but now when I run ndk-build, absolutely nothing happens. It just comes right back to the command prompt without displaying anything. I tried ndk-build -n and it shows 3 rm commands being executed and nothing else. I tried ndk-build -B and it makes no difference. I tried ndk-build -d and there is nothing in the output related to my source files or the name of the library.
If I change the make file back to build the shared library, it compiles the source and links the .so with no problems.
Anyone have any ideas what could be wrong?
It seems that in order to build a static library, it must be a dependency of something. I was able to build my library as static by adding an Application.mk file with the following line:
APP_MODULES = mylib
Related
I have successfully build libcurl for android as a shared library, both armeabi-v7a and x86, and one of my project depends on it. I have set "LOCAL_SHARED_LIBRARIES := libcurl", the problem is where should I put those libcurl.so files?
I tried putting them under (project)/jni/lib/(platform)/libcurl.so, and ndk-build gives me a whole load of linking error. (project)/lib/(platform)/libcurl.so will not work too because ndk-build will clear this directory before build.
So I tried again, building 1 platform at a time, however I still have no idea where to put it. jni/libcurl.so will not work.
Simple, follow this, download curl source from http://curl.haxx.se/
- prepare the toolchain of the Android NDK for standalone use; this can
be done by invoking the script:
./build/tools/make-standalone-toolchain.sh
which creates a usual cross-compile toolchain. Lets assume that you put
this toolchain below /opt then invoke configure with something like:
export PATH=/opt/arm-linux-androideabi-4.4.3/bin:$PATH
./configure --host=arm-linux-androideabi [more configure options]
make
Done.
I wonder if anyone did managed to build the fresh SDL2 with the toolchain of the Android NDK(r8d).
SDL2 seems to be very close to the release (since yesterday it isn't "UNDER CONSTROCTION anymore: http://hg.libsdl.org/SDL/rev/0a3d2ec7af6d). It comes with an Android.mk and just compiles fine following the instructions in the bundled README.android file. My question is whether there's really no working automake based build is available or will be available to compile it on Android, or something's wrong with my toolchain setup?
I have installed the NDK toolchain following the instructions of the documentation located at $NDK/doc/STANDALONE-TOOLCHAIN.html. I'm using gcc 4.6. Here's one environment i use:
#!/bin/sh
export TOOLCHAIN=$HOME/Android/android-14-arm
export PATH=$TOOLCHAIN/bin:$PATH
export SYSROOT=$TOOLCHAIN/sysroot
export CROSS_COMPILE="arm-linux-androideabi"
export CC=$CROSS_COMPILE-gcc
export CXX=$CROSS_COMPILE-g++
export CPP=$CROSS_COMPILE-cpp
export CFLAGS="-march=armv7-a -mfloat-abi=softfp -mfpu=neon"
export LDFLAGS="-march=armv7-a -Wl,--fix-cortex-a8"
echo "Compiler set up for ARM 14"
The configure params:
./configure --host=arm-linux-androideabi --prefix=$SYSROOT/usr/local
With the same configuration i successfully built libjpeg-turbo v8 and SDL_image.
The configure script recognizes the cross-compiler, and builds the makefile, however, it finds X11 support, can't see the OpenGL ES... The make fails:
In file included from /usr/include/features.h:378:0,
from /usr/include/sys/types.h:27,
from ./include/SDL_stdinc.h:35,
...
I checked the configure log, i have no idea where the "/usr/include" comes from.
But in fact, the generated makefile adds that line in the EXTRA_CFLAGS to the compiler.
The NDK doc refers the --with-sysroot=$SYSROOT as optional, i've included it to see if it solves the problem, but that didn't help.
As a last effort i manually edited the Makefile, fixing that reference, and now the compiler complained about X11.h.
AFAIK Android has nothing to do with X11, so i guess the whole build-tree completely inappropriate to use with NDK.
I have also tried a different configuration, found in an older thread here.
Neither defining -DANDROID -mandroid -fomit-frame-pointer nor changing back to -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb" solved the problem.
On previous projects, i had to refresh config.guess, and config.sub in order to get my compiler recognized. SDL doesn't seem to use those. Furthermore no Makefile.ac or Makefile.am comes with SDL to work with, and no templates for other platform could be used for a good starting point to create my own makefile. Additionally, i've never had to deal with makefiles, i really have no chance to sort out these problems. Even if it succeeds, i will probably need a configure tool as well, since i have no idea how ndk-build manages to install SDL2 without configure scripts.
Compiling the SDL sources with the project together is the only working - but ugly solution. I would like to deploy the necessary lib and header files by make install.
I hope the solution is something really easy and obvious thing that i just didn't think about...
This issue has been fixed at http://hg.libsdl.org/SDL/rev/4e57cfd9fca8 and expected for the 2.0.4 release. Note there are newer revisions with some related fixes about defines.
We have a problem building out C++ software on Ubuntu Linux with qmake.
Problem is: we use some library, for example OpenCV, that can have different versions in one system.
qmake automatically add -L/usr/lib or -L/usr/lib/x86_64-linux-gnu to g++ arguments, and contents of LIBS variables after it.
So there conflicts with different versions of OpenCV, the system version is used, but we need custom one, located at our build tree.
Are there any methods to change libs order in -L or something else to solve this problem?
There are two components to doing this:
First, you need to make sure to include them in your .pro file correctly. Do this with something like (this is from my current project):
LIBS += L${OPENCV_HOME}/lib \
-lopencv_core \
-lopencv_highgui \
You can replace the environment variable with whatever your path is. I've found it convenient to use environment variables like this because you also need header includes:
INCLUDEPATH += $$(OPENCV_HOME)/include/opencv2 \
$$(OPENCV_HOME)/include/opencv \
$$(OPENCV_HOME)/include
This allows you to create projects and build them correctly.
When you attempt to run them, however, you will likely run into all sorts of issues due to your app finding the wrong libraries (from system libraries like you say) - you need to set your LD_LIBRARY_PATH variable correctly. In this case I have a launch script (you can do this in your user profile or elsewhere) which contains:
export LD_LIBRARY_PATH=${OPENCV_HOME}/lib
Which then looks to that (as well as other) locations on the LD_LIBRARY_PATH first, before system libraries.
Another hack is to exploit the LIBS = $(SUBLIBS) ... part of the Makefile qmake writes.
Namely, invoke the generated Makefile with
make SUBLIBS=-L/path/to/your/opencv
I had the same issue which I fixed by setting QMAKE_LIBDIR to the lib directory of the build tree. QMake automatically added the system library path after this value, thus allowing to correctly detect the desired libraries:
QMAKE_LIBDIR = /path/to/desired/opencvlib
I have two OpenCV versions on my PC, one installed by default in /usr and another installed by compiling the sources in a custom dir (not /usr).
The first worked just fine with Qt, the other didn't. I struggled a lot trying to make the Qt Creator work with my OpenCV compiled sources. So I added -L/opencv_lib_path but it always said 'undefined reference' for some OpenCV API I was using. It simply doesn't want to look there for the libs, it will look in LD_LIBRARY_PATH instead. I tried adding my opencv_lib_path to the LD_LIBRARY_PATH, no joy either.
The only thing that worked was Frodon's solution, just add this in your Qt .pro file and it will work.
QMAKE_LIBDIR = /path_to_installed_opencv/lib
I currently compiled a set of source code in C in Linux and the output is a *.o file which is a object file. This supposedly does image compression. Now I want to use/test this in Android.
Is this possible? I have only tried NDK examples from the Android NDK developer side. Have not came across any reference on how this can be done.
Thanks In Advance,
Perumal
You don't run object code files (*.o). You would need to turn it into an executable. To do this, assuming you are using GCC you would run gcc file1.o file2.o -o executable which would convert a two file program with file1.o and file2.o into an executable called executable.
Object files (ending in .o) usually contain code that is incomplete. For example, if your program uses some library to print something on screen, to produce an executable, you must link your compiled code (the .o file) with the library, so that when the operating system loads the executable knows all the code that will be used. You do this linking with a linker (such as ld in Linux, or /system/bin/linker in Android). In your case, it's easier to let gcc call the linker for you, as Jalfor notes.
The answer is Yes. But you have to do some fair amount of work to see it running on Android.
1) If you are compiling on Linux, it means the object file or the final executable is being built for the x86 or AMD processor(Mostly). But mostly all the mobile devices have ARM processors running on their phones. So, though you have an executable you will not be able to execute it in ANdroid if it is not built for ARM Cpu. This is what android NDK does exactly.
2) So, we have to build the same code again for Android(ARM), for which we need a cross-compiler and the source code of the object files you are talking about.
3) If you have source code avilable, you can do 2 things again.
To include it in JNI folder, build the shared library and then do the
stuff of calling and all.
Build the code into an executable(Note you need to have main
inside the code) using the android NDK and then push the executable inside Android using
adb.
Now finally you can login and then check the result. In case anything is not clear, please do let me know. I wont mind explaining. Thanks..
I'm trying to implement an open source library that is built using the GNU compiler. (namely, this: https://github.com/mjwybrow/adaptagrams )
I've tried opening and building that source code using VSC++ 6, but it results in over a thousand errors due to the strict nature of the VS compiler I guess. And rather then go through every error and try fix it myself, I was wondering if it's possible to just include the .lib if it is built with the GNU compiler?
EDIT:
Included in the source code linked above is an autogen.sh file.
mkdir -p m4
autoreconf --install --verbose
automake -a --add-missing
./configure
make
Running that with Cygwin results in a few .a library files to be created, which are unusable in VS. Is it ok to just rename these to .lib files?
I've found some stuff online about how to use GCC and create a DLL, but my problem is that I don't know enough about the GNU compiler or makefiles, or the source code in general to be able to change it right now.
Does anybody have any clues on what exactly I'd need to change to get it right? Or even better, has anyone created a DLL using this source code already that would be able to pass it on to me, or let me know what I have to do?
Or could anyone point me towards a similar library that would be compatible with visual studio?
No; you can however build the .dll file with gcc and use the .dll from msvc (with either a hand-crafted include file or a properly formatted one from the beginning, with platform specific import/export macros on top).