Develop Reference

How to build boost 1.69.0 for Android with NDK r18b using dec1/Boost-for-Android?

I tried to use https://github.com/dec1/Boost-for-Android to compile boost for Android. It reports 1.69.0 is supported for NDK r18b. I'm under Windows 7.
Even if this is reported as working, I encounter many problems when trying to run the provided script:
Downloaded boost 1.69.0
Downloaded sources
Modified BOOST_SRC_DIR to point to folder containing "1.69.0" boost folder
Modified ANDROID_NDK_ROOT to point to ndk folder
Modified ABIS="armeabi-v7a,x86"
Modified LINKAGE="static"
Added Cygwin to my path (as this is a .sh file I need to run)
Ran doIt.sh
Got non blocking errors:
-nLe fichier sp?cifi? est introuvable.
ERROR: Unsupported HOST_TAG: windows-x86_64
Then I got final error
## COMMAND: mkdir /tmp/ndk-/tmp/build-11600/build-boost/armeabi-v7a/llvm/host-bin
## COMMAND: ./bootstrap.sh --with-toolset=cc Building Boost.Build engine
with toolset cc... Failed to build Boost.Build build engine Consult
'bootstrap.log' for more details ERROR: Could not bootstrap Boost build
'bootstrap.log'reports gcc: not found
Added MinGW to my PATH (to have gcc be found), then retried:
Now I get in 'bootstrap.log':
cc -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c class.c cwd.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c pathunix.c
command.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
There is no 'cc' available in my PATH, dunno where this is supposed to be found
Any idea what I may be doing wrong?

Sorry, only building on linux is officially supported. Mac and Windows should work fine too but details of setting up the relevant environments (eg cgwin or homebrew) is beyond the scope of what this project tries to do.
If you want to use windows as a host you have two easiest options are:
Use virtual machines eg. VirtualBox or and create a linux virtual machine where you do the building.
You can also simply download and use the precompiled binaries I have made available
No matter what os you use to build under, the resulting binaries can then be copied to windows and used from then on as if you had built on windows to start with (theyre cross compiled for android).

Compile and use boost for Android NDK R10e

How do I compile and use Boost for the Android NDK? I've tried everything I've found online, from Boost for Android to compiling it myself with the bjam file. However, I do not succeed. When I try compiling it with bjam, I get the following error:
error: toolset gcc initialization:
error: version 'androidR10e' requested but 'g++-androidR10e' not found and version '4.2.1' of default 'g++' does not match
error: initialized from /path/to/android-ndk-r10e/sources/boost/tools/build/v2/user-config.jam:86
Has anyone successfully used Boost with Android NDK R10e?
And when I can compile it, how should I do to use it in my Android app project?

We managed to compile it for NDKr10d. It should be the same for NDKr10e.
The project-config.bjam should point to the gcc compiler from the NDK. Ours looks like this :
import option ;
using gcc : arm : D:\\android\\ndk\\toolchains\\arm-linux-androideabi-4.9\\prebuilt\\windows-x86_64\\bin\\arm-linux-androideabi-g++.exe ;
option.set keep-going : false ;
Then just compile with b2, telling paths to android includes :
b2 --reconfigure <your options>
toolset=gcc-arm
include=<ndk folder>\sources\cxx-stl\gnu-libstdc++\4.9\include
include=<ndk folder>\sources\cxx-stl\gnu-libstdc++\4.9\libs\<target platform>\include
include=<ndk folder>\platforms\<android api version>\arch-arm\usr\include
install --libdir=stage\lib\<target platform>
We're about to move to ndkr10e. Could you tell if boost still works with it ? :)

The simplest way would be to use CrystaX NDK, which contains already built and ready-to-use Boost libraries. And here are examples how to use Boost with CrystaX NDK: 1, 2

Following the boost directions, I was able to build boost 1.60 with NDKr10e on Ubuntu 12.04 (although I suspect very little depends on the host system). Here are my notes:
get and unpack boost source tarball (i used 1.60): boost_1_60_0.tar.bz2
moskewcz#maaya:/scratch/moskewcz/android/src$ ll
total 74M
drwx------ 10 moskewcz moskewcz 4.0K Mar 9 14:14 boost_1_60_0
-rw-rw-r-- 1 moskewcz moskewcz 74M Jan 5 11:15 boost_1_60_0.tar.bz2
follow boost instructions in getting started on unix "Build Custom Binaries" section
use a fresh, empty root to install b2 i.e. /scratch/boost-build-root; use usr as prefix; again following the boost instructions:
moskewcz#maaya:/scratch/moskewcz/android/src/boost_1_60_0/tools/build$ ./bootstrap.sh
moskewcz#maaya:/scratch/moskewcz/android/src/boost_1_60_0/tools/build$ ./b2 install --prefix=/scratch/moskewcz/android/boost-build-root/usr
put b2 in path (again as per instructions)
export PATH=/scratch/moskewcz/android/boost-build-root/usr/bin:$PATH
in some jamfile (i had no ~/user-config.jam, so i created one and used that, maybe there's a better choice of jamfile to create/edit) add some jam-code (?) to define a gcc version (toolset) pointing to a g++ from a standalone toolchain. note that this is a toolchain created with the NDK in the normal fashion following its 'create a standalone toolchain' directions. i am NOT pointing to a g++ inside the NDK itself (that may or may not work, i dunno):
import option ;
using gcc : arm_linux_android_4.9 : /scratch/android-stc/bin/aarch64-linux-android-g++ ;
option.set keep-going : false ;
go to boost project root and build, mostly as per directions. --build-dir may be optional? also added -j8 to do || build
moskewcz#maaya:/scratch/moskewcz/android/src/boost_1_60_0$ b2 -j8 --build-dir=bin.v2 toolset=gcc-arm_linux_android_4.9 stage
note that this tries to build both static and shared libs by default, but building shared libs fails due to android not having librt.so -- according to my research, people claim that under android (some of?) the functionality of librt.so is inside libc.so -- so it may be okay to simply remove -lrt from the linking steps in order to build shared libs for android. i did not attempt this. see:
https://code.google.com/p/android/issues/detail?id=5730
Building Boost for Android with error "cannot find -lrt"

I only managed to build with 10d. Cross compiling Linux->Android using Boost for Android worked straight away with that.
To download a slightly outdated ndk, as not all ndk are immediately supported by Boost for Android, you can use this guide: Where do I find old versions of Android NDK?
Note: I also wanted to specify the toolchain. I had to do it in 2 places:
In build-android.sh, just after the line mentioned here above:
TOOLCHAIN=${TOOLCHAIN:-arm-linux-androideabi-4.9}
In the command line
bash build-android.sh [ndk location] --toolchain=arm-linux-androideabi-4.9
In fact, it worked better when I specified exactly which boost components I wanted with --with-libraries=[comma separated list].
If instead I would build everything, I would get:
...failed updating 38 targets...
...skipped 6 targets...
...updated 10568 targets...
ERROR: Failed to build boost for android!
Done!

Here: http://silverglint.com/boost-for-android/ you can find a simple and painless new way to build a modern (eg 1.64.0) version of boost for android.
Works with clang and gcc.
Also included is a sample app that shows you how to use the boost binaries thus built.

Cross-Compiling Swiften library for ARM-embedded with SCons makery

Swiften is a XMPP client library and my objective was to build it for a ARM-embedded target running Linux.
I hacked my way to a successful cross-compile with little knowledge of SCons. I'll lay out my hack here with the hope that someone can point me to a maintainable solution using the two makery files, SConscript.boot and SConstruct.
I had two tasks (neither accomplished satisfactorily):
Successfully switching the tool-chain from native-compile to cross-compile
Ensuring that OpenSSL libraries were successfully linked (not supplied by the swiftim project; they has to be installed and built in the 3rdParty folder).
Switching the tool-chain from native-compile to cross-compile for ARM
My ARM cross tool-chain components, gcc, g++, ld, etc are located here.
/opt/toolchain/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/arm-linux-gnueabihf/bin/
I couldn't find a way to tell scons to use the cross tool-chain (from the above location) instead of the native tool (in the usual place, /usr/bin). Prefacing the invocation (./scons Swiften) with the fully-qualified values for the environment variables, CC and CXX didn't work (while not recommended, its alluded to in one place).
Scons would only pick up the native tool-chain even after many ad hoc changes to the makery.
So, as a hack, I had to change the native tool-chain to point to the cross tool-chain.
/usr/bin/gcc -> /opt/toolchain/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/bin/arm-linux-gnueabihf-gcc-4.7.3*
/usr/bin/g++ -> /opt/toolchain/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/bin/arm-linux-gnueabihf-g++*
The first compile-break for ARM was fixed by adding the line below to the default portion of the build script, SConscript.boot.
env.Append(CPPDEFINES = ["_LITTLE_ENDIAN"])
The next compile-break has to do with the OpenSSL header files not being found. To fix the location issue, I had to introduce the line below into SConscript.boot
vars.Add(PackageVariable("openssl", "OpenSSL location", "/home/auro-tripathy/swiftim/swift/3rdParty/OpenSSL/openssl-1.0.1c/"))
Linking with OpenSSL
For the sample Switften programs to link with the OpenSSL libraries, I had to move libssl.a and libcrypto.a (built separately) from the location they were built to the toolchain library-location like so.
mv ~/swiftim/swift/3rdParty/OpenSSL/openssl-1.0.1c/libcrypto.a /opt/toolchain/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/lib/gcc/arm-linux-gnueabihf/4.7.3/.
Help
Not understanding of the working of scons, I've made some hacks to get it to work.
I’d like some help to:
Introduce a new target called ARM-embedded, just like other targets; iPhone, android, etc
Clean way to integrate OpenSSL into the build .
Update
Per dirkbaechle, retried the script below and it works
export CC=/opt/toolchain/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/arm-linux-gnueabihf/bin/gcc
export CXX=/opt/toolchain/gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux/arm-linux-gnueabihf/bin/g++
./scons Swiften

Brady's answer is correct, regarding how you'd do it in plain SCons. I'd just like to mention that the top-level SConstruct of Swiften already provides arguments like "cc=" and "cxx=" for using local toolchains.
You might want to inspect the ouput of scons -h for a complete list of available options.
In addition, the SConscript for the OpenSSL build expects the sources to be located in the relative folder named "openssl", not "openssl-1.0.1c" as in your case. Maybe that's where your build problems are mainly coming from.

I left a comment above regarding the cross-compilation. Its already been answered in the link provided, but basically you just need to set the appropriate construction variables: CC, CXX, LINK, etc.
As for a "Clean way to integrate OpenSSL into the build" this can be performed simply by adding library and include paths appropriately as follows replacing the quoted values appropriately:
(without having to copy/move the original files)
# This sets the location of the OpenSSL Include paths
env.Append(CPPPATH="path/to/openssl/includes")
# This sets the location of the OpenSSL Libraries
env.Append(LIBPATH="path/to/openssl/libraries")
# These are the OpenSSL libraries to be linked into the binary
env.Append(LIBS=["OpenSSL_lib", "OpenSSL_lib2"])

The choice of compiler, and additional flags, can all be set in Swift's config.py file. A snippet from config.py using a custom compiler and flags is below (the one I use on one of my dev boxes):
cc = link = "/usr/local/llvm-git/bin/clang"
cxx = "/usr/local/llvm-git/bin/clang++"
bothflags = " -std=c++11 -stdlib=libc++ -nostdinc++"
cxxflags = bothflags + " -I/usr/local/libcxx/include -Wno-deprecated"
linkflags = bothflags + " -L/usr/local/libcxx/lib"
This should work for cross-compiling in the same manner.
To use a bundled openssl, you should just be able to extract into 3rdParty/OpenSSL, and add openssl_force_bundled = True to your config.py. You should not need to fiddle with setting include paths to this yourself. It's conceivable that this is tied to a particular openssl release as I've not compiled a bundled openssl since 1.0.0a, but if it doesn't work with the current version it's probably a bug that ought to be fixed. You could also cross-compile openssl yourself and use openssl='/path/to/openssl', but that's a little more of a nuisance for you.

Using Boost in android ndk with windows

I am trying to use boost library with Android ndk in Eclipse with Windows. I tried to follow this tutorial
I am stuck in the step with "bjam" command in cygwin.
bjam --without-python --without-serialization toolset=gcc-android4.4.3 link=static runtime-link=static target-os=linux --stagedir=android
Error: bjam command not found.
What is bjam? Also I used the boost 1.53 along ndk r8e. Can someone help me with this please?

Android NDK is no longer dependent on Cygwin, so you can build Boost with the NDK from within Windows command prompt (cmd).
In order to make Boost.Build find the NDK, edit boost\tools\build\v2\user-config.jam file and append the following text:
import os ;
androidNDKRoot = C:/android-ndk-r8e ; # put the relevant path
using gcc : android :
$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-g++ :
<compileflags>--sysroot=$(androidNDKRoot)/platforms/android-9/arch-arm
<compileflags>-mthumb
<compileflags>-Os
<compileflags>-fno-strict-aliasing
<compileflags>-O2
<compileflags>-DNDEBUG
<compileflags>-g
<compileflags>-lstdc++
<compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.7/include
<compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/include
<compileflags>-D__GLIBC__
<compileflags>-D_GLIBCXX__PTHREADS
<compileflags>-D__arm__
<compileflags>-D_REENTRANT
<archiver>$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-ar
<ranlib>$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-ranlib
;
Certainly, instead of c:/android-ndk-r8e you have to put the right location of the NDK on your PC.
Besides, you can select more recent platform API, instead of android-9.
Also note that the NDK supplies several tool-chains, and the above settings point to gcc-4.7. If you prefer to build boost with some other tool-chain, change arm-linux-androideabi-4.7 to the relevant path.
After you've put the configuration in user-config.jam, open cmd, cd to the directory where Boost resides, and invoke bootstrap. Then invoke b2 like this (for example):
b2 --without-python --without-serialization threading=multi link=static runtime-link=static toolset=gcc-android target-os=linux threadapi=pthread --stagedir=android stage
UPDATE: As of 11/2015, older NDK toolchains seem to have issues with the newer Boost versions, causing compiler crash, so consider using a more recent compiler. To do this, just change every 4.7 occurrence in the above script to 4.9. Also, it's worth compiling with a more recent Android API (eg. andoroid-9 -> andoroid-16 or so).

How to build i686-linux-android-gfortran for android-ndk8b (x86 arch Android)?

I tried building i686-linux-android-gfortran using build-gcc.sh following this
(it's for androdindk-7b) but I get error about link.h. I added link.h from here, but it gives further more errors.
Has anyone tried enabling i686-linux-android-gfortran for x86 Android?

From https://groups.google.com/forum/#!msg/android-ndk/QR1qiN0jIpE/g0MHkhTd4YMJ as selalerer suggested. I didn't try this, so I'm posting as a community wiki for reference purposes.
Fortran for x86 Android
=================
The guide is based on this one, many thanks to Phil:
Compiling Android NDK with Objective-C-enabled gcc errors
1) Download and unpack Android NDK 'android-ndk-r8c', (the older -r8b NDK won't work due to missing link.h!):
wget http://dl.google.com/android/ndk/android-ndk-r8c-linux-x86.tar.bz2
2) Create somewhere a folder called 'toolchain-src' (e.g. inside the folder android-ndk-r8c),
'cd' to this new folder
3) Make sure to have git installed ('yum install git' or whatever..) and download
the toolchain sources:
git clone https://android.googlesource.com/toolchain/build.git
git clone https://android.googlesource.com/toolchain/gmp.git
git clone https://android.googlesource.com/toolchain/gdb.git
git clone https://android.googlesource.com/toolchain/mpc.git
git clone https://android.googlesource.com/toolchain/mpfr.git
git clone https://android.googlesource.com/toolchain/expat.git
4) Create the folder 'binutils', 'cd' to this directory, unpack
binutils-2.23 there:
wget ftp.gnu.org/gnu/binutils/binutils-2.23.tar.gz
tar -xvzf binutils-2.23.tar.gz
You should now have a folder toolchain-src/binutils/binutils-2.23
5) Change to folder toolchain-src/build, edit the Makefile.in, changing the line:
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
to
--with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran
6) In the file android-ndk-r8c/build/tools/build-mingw64-toolchain.sh change the line:
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++"
to
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++,fortran"
7) In the file android-ndk-r8c/build/tools/build-gcc.sh, change the line:
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-plugin"
to
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin"
8) In the file android-ndk-r8c/build/tools/build-host-gcc.sh, change the line:
ARGS=$ARGS" --enable-languages=c,c++"
to
ARGS=$ARGS" --enable-languages=c,c++,fortran"
And change the line
ARGS=$ARGS" --disable-libquadmath --disable-plugin --disable-libitm --disable-bootstrap"
to
ARGS=$ARGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin --disable-libitm --disable-bootstrap"
9) Build your new toolchain:
/your/path/to/android-ndk-r8c/build/tools/build-gcc.sh -j1 --gmp-version=5.0.5 --mpfr-version=2.4.2 --mpc-version=0.8.1 --binutils-version=2.23 --gdb-version=7.3.x /your/path/to/toolchain-src /your/path/to/android-ndk-r8c x86-4.7
(don't worry about messages like 'expr: warning: unportable BRE:')
10) And go down to your knees in front of the screen, praying to the Lord that somehow these
countless configure scripts doing checks that nobody needs, using an ugly shell language
that cooks your brain with indentation going from right to left, will somehow manage to
compile a zillion of far too small files (so that 10% of the time is spent on compilation
and 90% on starting up GCC), and after an hour of watching progress with
tail -F /tmp/ndk-YourUserName/build/toolchain/config.log
your toolchain will be magically ready. You'll find it in the android-ndk-r8c/toolchains folder.
11) Finally, 'cd' to the folder
'/your/path/to/android-ndk-r8c/toolchains/x86-4.7/prebuilt/linux-x86/i686-linux-android'
and run this command:
ln -s ../libexec libexec
Without this command, it may happen that g++ raises the error message
"g++: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found".
Using strace, I found that g++ looks in the wrong folder, but the link
above lets it find the file liblto_plugin.so nevertheless.
And here are a few lessons learned on the way, so that Google finds this page:
*) To speed up the compilation, you can remove the '-j1'. But only after you got
it to work once, since building in parallel on multiple CPU cores was reported to
cause additional troubles.
*) The error message "Link tests are not allowed after GCC_NO_EXECUTABLES" shows up
when linking fails for x86 (works for ARM). The reason is that GCC does not include
the proper ANDROID_STARTFILE_SPEC and ANDROID_ENDFILE_SPEC from
gcc-4.6.1/gcc/config/linux-android.h. GCC 4.6.1 only specifies them for ARM, but not
for i386, GCC 4.8.0 however does. The GCCs downloaded from Google also do,
so best use Google's GCC.
*) The error message "fatal error: link.h: No such file or directory" also happens
with Google's GCC, and apparently (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50877)
only when you enable additional languages like objc or fortran.
The bug thread is here: http://gcc.gnu.org/ml/gcc-bugs/2012-08/msg00494.html
MIPS has link.h in android-ndk-r8b/platforms/android-9/arch-mips/usr/include
In android-ndk-r8c, link.h is now also present in android-9/arch-x86/usr/include/link.h,
so this bug was fixed.
*) The error message "fatal error: quadmath_weak.h: No such file or directory":
It also happens with the latest gcc-4.8, so we can just continue using Googles GCC 4.7.
Google itself uses --disable-libquadmath, but we additionally need --disable-libquadmathsupport
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648). So this needs to be added in
android-ndk-r8c/build/tools/build-gcc.sh
and
android-ndk-r8c/build/tools/build-host-gcc.sh
*) The error message "error: Pthreads are required to build libatomic"
Happens when building the ARM version of gcc-4.8 downloaded from gnu.org,
better stay with Google's GCCs.
*) The GCC that came with android-ndk-r8c didn't work for me (error message about
libstdc++.so.6 being too old), while the one in android-ndk-r8b worked
without problems. Since the android-ndk should support as many environments
as possible, I'm not sure why the Googlers decided to depend on a newer libstdc++,
but the good news are that building your own toolchain solves the issue.
*) If you get an error while compiling generic-morestack.c, then replace
#ifdef linux
// On Linux, the first two real time signals are used by the NPTL
with
#if defined(GLIBC) && defined(linux)
// On Linux, the first two real time signals are used by the NPTL