I've recently started to cross compile a couple of C applications for Android. I've successfully done this for image conversion software using the following pseudo-instructions:
Build the Android toolchain
Compile Automake and Autoconf
Set the CC and CXX environment variables
Build the source package (delete configure, configure.sub, configure.guess, run autoconf configure.ac > configure, run configure with CFLAGS using arm-linux-androideabi, make and make install)
I am now trying to do this for an OCR library written in C. The problem that I am running into is that the library has no configure, configure.guess, or configure.sub. It only has a makefile.
I am not too familiar with C, but is there any different process that I should be following in this situation?
The ./configure step:
CFLAGS=’-march=armv7-a –mfloat-abi=softfp’ ./configure –prefix=/home/user/Downloads/install/usr/local –host=arm-eabi –enable-shared=no –with-modules --enable-delegate-build
is there any different process that I should be following in this situation?
Not really. I mean, if you plan to work with the Android Standalone Toolchain, then all you need to do is:
create the toolchain with the ad hoc target, e.g --platform=android-9
add the toolchain directory to the PATH (for convenience)
export the sysroot path, e.g. export SYSROOT=/tmp/my-android-toolchain/sysroot (for convenience)
set your C compiler (export CC="arm-linux-androideabi-gcc --sysroot $SYSROOT") and archiver, if you target a static library (export AR=arm-linux-androideabi-ar)
Then it all depends about how your Makefile has been written, i.e what are the targets? influential environment variables? etc. But in practice, if the default target fits your need, all you need to do is to run make while overriding the C flags to set the target architecture (ARMv7 here):
make CFLAGS="-march=armv7-a"
That's it. Repeat with other archs (armeabi, x86, etc) if needed.
You can see a complete example for jsmn - a lightweight JSON parse written in C, here: http://git.io/ndk-jsmn.
I've also a set of slides that cover this topic that you may find useful.
According to this article: What does a typical ./configure do in Linux?
configure only checks for system dependencies (if they are missing it exits), checks the type of system you are on, adn then creates a makefile. since you already have a makefile, you should already be able to execute make install.
Related
Am using a Customized Android Compiler. That compiles cpp code and generates the .so file. From Command Prompt it is working fine but when I try to Build using Cmake then Cmake always picks wither Clang or GNU Compiler for Android compilation even after setting the compiler name in toolchain file.
My Analysis and Findings are as below.
I am working towards creating a toolchain file for an ANDROID compiler
I understand that the flow in CMAKE, when CMAKE_SYSTEM_NAME is specified in Android is different when compared to specifying CMAKE_SYSTEM_NAME as IOS or LINUX
Please validate my current understanding when a toolchain file or command-line option sets CMAKE_SYSTEM_NAME to "Android"
CMakeDetermineSystem.cmake loads this file: Android-Determine.cmake
Next is the platform-specific initialization step: CMakeSystemSpecificInitialize.cmake which loads Android-Initialize.cmake to select the sysroot.
A "determine" step also runs for each language when it is first enabled in a new build tree:
Android-Determine-C.cmake
Android-Determine-CXX.cmake
The language files go here:
Determine-Compiler.cmake
Determine-Compiler-NDK.cmake
The latter file is where we parse a bunch of information from the NDK.
The results persist in CMakeFiles/$v/CMake${lang}Compiler.cmake for future runs.
Next is the language-specific initialization step. For Example – in case {lang} is C : CMakeCInformation.cmake
That loads one of these:
Android-GNU-C.cmake
Android-Clang-C.cmake
which loads one of these:
Android-GNU.cmake
Android-Clang.cmake
Determine-Compiler-NDK.cmake is where cmake looks for versions of clang or gcc or llvm toolchains and sets the appropriate compiler.
Our Requirement and Problem statement
When I tried manually setting a c and cxx compiler from a toolchain file, cmake would not allow me to point to my custom compilers. Ideally, I would want my toolchain file to tell cmake the libraries to include/link and the compilers to use. But once System has been determined as android, cmake goes through the above sequence of events and expects toolchains to be specified for either clang, gcc or llvm compilers.
I believe I would probably need to make changes in the following files to accommodate cmake to use custom compilers.
Determine-Compiler-NDK.cmake - We would need to add support for an "NewCompiler Toolchain" which would contain android libraries and compilers.
New Android-{NewCompiler}-C.cmake, Android-{ NewCompiler }-CXX.cmake, Android-{ NewCompiler }.cmake and another appropriate toolchain file to set target architecture and compiler flags.
Any comments on the process or how to go about this would be appreciated.
Toolchain files can set the path to compilers on the host, but
target-platform-wide information like the set of libraries and
include directories to use typically belongs in platform information
modules (e.g. Platform/Android-... and the like).
Since your compiler doesn't come with the NDK, perhaps you could look
at using the standalone toolchain mode.
I've got a hold of a proprietary JNI application which I need to build for a MIPS device. I've read "Initializing a Build Environment", parts of the NDK docs, some Google Groups threads and numerous StackOverflow questions, but I'm still short of my answer.
So far, I've checked out the Android source using Google's repo script and have it under ~/AndroidSource. I've also separately downloaded the SDK under ~/AndroidSDK and the NDK under ~/AndroidNDK. The code I'm trying to build is in a separate location. The SDK and NDK binaries are in my path. For building, I tried to use two different versions of the NDK as well as the one under the Android source tree, and experienced different sets of problems. My current setup uses NDK r8b, downloaded separately from the Android source.
The application has its Android.mk and jni/Android.mk. However, several directives in the latter point to paths such as
frameworks/base/include
system/core/include
with no prefixes. I thought these were meant to point to the respective directories in the Android source, so I symlinked them to the current directory. After some more symlinking and makefile and source hacking, I got the application to compile, but am currently stuck on the linking phase with lots of references to missing method bodies. During the whole time I knew I was doing something wrong.
I'm on a Linux x86_64 host, if it is of any concern.
So my question is:
What is the proper method to set up a build environment for JNI applications? What environment variables, symlinks and/or path expansions should I set up? Do I need to call any scripts once or before each ndk-build invocation?
Also, I'd be happy if you corrected me on any concepts or terminology I've gotten wrong.
Your approach wiyh symlinking the AOSP tree for system headers is correct. What you need now are the system libraries compiled for MIPS. The easiest way to get them is to adb pull them from a target device (or emulator image). But you can also build these libraries yourself, as part of the AOSP build (see build instructions for the source tree you downloaded).
If you still have any problems remaining, run your ndk-build with parameter V=1 and publish the link command and its results.
I use the following in my build (YMMV).
Explicitly invoke arm-linux-androideabi-gcc as your compiler or linker (should be in PATH).
NDK_PLATFORM=/path/to/android-ndk-r*/platforms/android-14
Pass -I"$(NDK_PLATFORM)/arch-arm/usr/include" to the compiler
Pass -nostdlib -L"$(NDK_PLATFORM)/arch-arm/usr/lib/" -lgcc -lc -lm to the linker
I am trying to understand what a standalone toolchain means.
Following are my findings.
A toolchain which is ready to use with all the configuration that is the system headers and libraries in the correct path . For Android it will also have the API headers in the path where the toolchain can look it up. Why the term "standalone"? This probably will be different that the regular toolchain in the sense that the R T will need to be configured and made ready for android use withe sysroot and libc header paths given etc.
Please comment .
Hmm, I was compiling for android and one process was running a script called make-standalone-toolchain.sh a standalone toolchain is created .I was going through this script to understand what this is doing. Not really good at shell scripting. But made out certain things. ""Generate a customized Android toolchain installation that includes a working sysroot. The result is something that can more easily be used as a standalone cross-compiler, e.g. to run configure and make scripts." --toolchain arch ndk-dir package-dir system platform variables are set Compute source sysroot
SRC_SYSROOT="$NDK_DIR/platforms/$PLATFORM arch-$ARCH" Copying sysroot headers and libraries... libstdc++ headers and libraries... prebuilt binaries.all into a temporary folder then a copying from Tmp dir to install
dir creating a tar ie a package file to add the tmpdir wanted to know what exactly is happening here or a link or suggestion where to look.but ofcourse dont want to read very elaborate manuals.
~
This blog posting may answer your question:
http://clseto.mysinablog.com/index.php?op=ViewArticle&articleId=3480794
There is a recommended way to build native C/C++ program on Android: List your source files in a script (Android.mk) and run 'ndk-build'. It may not be a problem if you are writing new programs but if you already have a working build script (like those open source softwares) which can build you program nicely on Linux, it would be a headache to migrate your script to Android.mk. All you need in this situation is a C/C++ cross compiler and then replace the variables in your script (such as CC, CXX, AR, AS, RANLIB, ...) to something like 'arm-linux-androideabi-gcc', 'arm-linux-androideabi-g++', ...
Fortunatley, inside the 'Android NDK Dev Guide', there is a section 'Standalone Toolchain' which just describes what we need....
First of all, the best guide for stand alone toolchains in Android is here: https://developer.android.com/ndk/guides/standalone_toolchain.
I have used it several times for different devices and platform.
You need to download NDK and then run the script 'make-standalone-toolchain.sh' with a few parameters (as said in the link above) that will determine the API levels of your apps, the architecture of the device etc.
The output of the script will be a directory that you can use as a toolchain in order to cross compile native C/C++ code to run on Android devices. You need to put in your Makefile the path to the toolchain directory and add the architecture suffix for the binaries inside (for example 'arm-eabi-'). Something like:
CROSS_COMPILE = /path-to-toolchain-dir/bin/arm-eabi-
There should be files like '/path-to-toolchain-dir/bin/arm-eabi-gcc' in your toolchain directory.
Anyway, this will tell the Makefile to use your toolchain's binaries in order to compile the C/C++ native code and create the compatible executables for your target machine.
For example, this is the commands I used to create a stand alone tool chain for a certaion Android device:
./make-standalone-toolchain.shj --arch=arm --platform=android-21 --install-dir=<dest-dir> --toolchain=arm-linux-androideabi-4.9
We have an application working fine for Mac and Windows platform, now targeting for Android and iOS,
Application using libxml for parsing of XML data, and my question is ?
1 -- Do i need to build libxml for Android platform or its already there as a part of NDK ?
if need to build any pointers how to start ?
You have two options:
Write an Android.mk that can successfully build libxml, and depend on the result of that in your main Android.mk. You can try to build libxml natively (using the configure script and make) on your Mac to get an idea of what files need to be built, and if any special flags need to be passed.
Or, Use libxml's configure script and build libxml for Android using the NDK's toolchain. You'll have to do something like this:
NDK_ROOT=/path/to/ndk
API_LEVEL=YOUR_API_LEVEL
SYSROOT=$NDK_ROOT/platforms/android-$API_LEVEL/arch-arm
export CC="$NDK_ROOT/toolchains/arm-linux-androideabi-4.4.3/Darwin-x86/bin/arm-linux-androideabi-gcc"
export CFLAGS="--sysroot=$SYSROOT"
export LDFLAGS="--sysroot=$SYSROOT"
./configure --host=arm-linux-gnueabi --enable-static --disable-shared
make libxml2.la
Technically the host triplet for Android is arm-linux-androideabi, but most configure scripts don't recognize it, and for our purposes here, -gnueabi is close enough.
I ended up suggesting make libxml2.la rather than just make because the tests weren't building properly. The resulting library will end up in the .libs/ folder.
The second method might be a little easier, but if you intend to build your app for multiple architectures (arm, armv7-a, maybe even x86 and mips), writing your own Android.mk will save you time in the long run.
I had some experience of android but know almost nothing of GCC Makefile. Here is what I need,
working on mac osx or linux, using android ndk toolchain, build an android shared library .so (a jni lib), linking in a prebuilt static library (already built for android). In static lib, I need logcat functions and C funcs such as sprintf. So no "ndk-build" in the process. The reason I have to do this, when linking in the static lib, a special linker is required to replace the standard arm-eabi-gcc, and the standard linker will be rolled back later.
I know that I need to set following environment variables such as:
ANDROID_NDK,
PATH=$PATH:"$ANDROID_NDK/build/prebuilt/darwin-x86/toolchain/arm-eabi-4.4.0/bin"
MACHINE=armv7l
SYSTEM=android
ARCH=arm
CROSS_COMPILE="arm-eabi-"
ANDROID_DEV="$ANDROID_NDK/platforms/android-8/arch-arm/usr"
HOSTCC=gcc
All I need is a sample Makefile, so that I can run "make" to build a .so by linking in a .a, and other necessary android and c libs.
Thanks
Try running ndk_build V=1 and recording the commands it issues in verbose mode. Then issue comparable commands to your custom linker.
Beware the commands might change for a different ndk version.