I want to install compile Boost 1.61 with clang 3.6 for android with the NDK 11 but this software : https://github.com/moritz-wundke/Boost-for-Android isn't updated and doesn't support this versions.
I want to know if anyone has managed to this !
Thank you !
Build boost_1_62_0 for Android-21 under Windows64.
Assuming NDK installed to C:\Programs\Android\sdk\ndk-bundle and boost in c:\boost_1_62_0.
Install mingw: using msys2-x86_64 from MSYS2
Install build tools from mingw prompt (something like this):
$ pacman -S gcc binutils
Create android.clang.jam file in C:\boost_1_62_0\ with such text content:
import os ;
local AndroidNDKRoot = C:/Programs/Android/sdk/ndk-bundle ;
using clang : android
:
C:/Programs/Android/toolchain21/bin/clang++
:
<compileflags>-fexceptions
<compileflags>-frtti
<compileflags>-fpic
<compileflags>-ffunction-sections
<compileflags>-funwind-tables
<compileflags>-Wno-psabi
<compileflags>-march=armv7-a
<compileflags>-mfloat-abi=softfp
<compileflags>-mfpu=vfpv3-d16
<compileflags>-fomit-frame-pointer
<compileflags>-fno-strict-aliasing
<compileflags>-finline-limit=64
<compileflags>-I$(AndroidNDKRoot)/platforms/android-21/arch-arm/usr/include
<compileflags>-Wa,--noexecstack
<compileflags>-DANDROID
<compileflags>-D__ANDROID__
<compileflags>-DNDEBUG
<compileflags>-O2
#<compileflags>-g
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/include
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include
<architecture>arm
<compileflags>-fvisibility=hidden
<compileflags>-fvisibility-inlines-hidden
<compileflags>-fdata-sections
<cxxflags>-D__arm__
<cxxflags>-D_REENTRANT
<cxxflags>-D_GLIBCXX__PTHREADS
;
Setup boost from mingw prompt:
$ export NDK=/c/Programs/Android/sdk/ndk-bundle
$ echo ensure msi-installed Python is on path (not msys version):
$ export PATH=/c/Python27:$PATH
$ $NDK/build/tools/make_standalone_toolchain.py --arch arm --api 21 --install-dir /c/Programs/Android/toolchain21
$ ./bootstrap.sh --with-toolset=gcc
$ ./b2 --user-config=android.clang.jam threading=multi link=static \
runtime-link=static toolset=clang-android target-os=linux \
threadapi=pthread --stagedir=android --with-chrono \
--with-program_options --with-system --with-thread --with-random \
--with-regex
Yes, the repository you mentioned is apparently not maintained anymore. The author also seems not to answer any mails on the subject. If you look you'll see that each new boost version supported there required a lot of work (many special flags in the config files). That's presumably why he doesn't have time to maintain it any longer.
I also tried to update to 1.64 using a fork but gave up after countless error messages and instead used a different method based on a crystax script. Its simple and should work for pretty much any version. You can find the details and the script (simple and painless to execute) here: http://silverglint.com/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.
Related
As you may know, Bionic is a C library used by Google to run Android applications. There are efforts to compile it in Linux machines, so it could be easily used outside Android. This is the code from one the latest efforts, originally called Gentoo-bionic. The original project was Gentoo-based, but the current source is not Gentoo-specific. I am using Ubuntu. Here's the code:
https://github.com/gentoobionic/bionic
And this is the presentation about it on ELC2013:
http://elinux.org/images/2/25/2013_elc_gentoo_bionic.pdf
http://free-electrons.com/blog/elc-2013-videos/ (bad sound)
I tried to compile it on X86_64 Ubuntu, but failed. I tried:
./autogen.sh
./configure
I got:
configure: error: unsupported host cpu x86_64
So I tried:
./configure --build=arm-linux --target=arm-linux --host=arm-linux
It configured fine, but I got:
$ make
make: *** No rule to make target `libc/arch-x86/include/machine/cpu-features.h',
needed by `all-am'. Stop.
Is there a chance that someone can suggest a workaround?
I dont know anything about bionic. I just want to help you.
when i viewed configure file, i saw this code.
Makefile.h.am:Line 135
if TARGET_ARCH_IS_X86
includemachine_HEADERS += \
$(addprefix $(top_srcdir)/libc/arch-x86/include/, \
machine/fpu_control.h \
machine/sigcontext.h \
machine/wordsize.h \
)
endif
if TARGET_ARCH_IS_ARM
includemachine_HEADERS += \
$(addprefix $(top_srcdir)/libc/arch-x86/include/, \
machine/cpu-features.h \
)
endif
configure.ac: Line 94
case $host_cpu in
*i?86*)
TARGET_ARCH=x86
COMMON_LDFLAGS="${COMMON_LDFLAGS} ${COMMON_LDFLAGS_X86}"
COMMON_CFLAGS="${COMMON_CFLAGS} ${COMMON_CFLAGS_X86}"
COMMON_INCLUDES="${COMMON_INCLUDES} ${COMMON_INCLUDES_X86}"
COMMON_LDLIBS="${COMMON_LDLIBS} ${COMMON_LDLIBS_X86}"
;;
*arm*)
TARGET_ARCH=arm
COMMON_LDFLAGS="${COMMON_LDFLAGS} ${COMMON_LDFLAGS_ARM}"
COMMON_CFLAGS="${COMMON_CFLAGS} ${COMMON_CFLAGS_ARM}"
COMMON_INCLUDES="${COMMON_INCLUDES} ${COMMON_INCLUDES_ARM}"
COMMON_LDLIBS="${COMMON_LDLIBS} ${COMMON_LDLIBS_ARM}"
;;
*)
AC_MSG_ERROR([unsupported host cpu $host_cpu])
;;
esac
There is no cpu-features.h file on include/machine folder. So, you have to use different target.
Since Nov 2015 my set of ebuid scripts compile bionic for x86_64 and i386 on my Gentoo x86_64 desktop. Tools required: glibc-targeting GCC version 4.9.3 or 5.3.0; binutils 2.4.25 or older, glibc-targeting clang 3.5.0, make.
If you can install those tools on your desktop, you can potentially compile bionic.
Note however that my ebuilds apply zillion of patches.
To see what they do, you can the following:
Boot live Gentoo DVD on a x86_64 desktop or notebook.
Install my scripts.
Run them capturing output, for instance
USE=verbose ebuild bionic/bionic-5.1.1-r29.ebuild clean install qmerge 2>&1 | tee /tmp/bionic.cout
Once such command terminates, you get the patched source tree, intermediate and final compilation result, and full build log with gcc/clang/ld/ar command-lines.
I'm experimenting with native libs cross compiled from ubuntu. What I really want is to be able to compile my c++ libraries and use them in a Xamarin.Android app.
First, I have the arm gcc compiler: arm-linux-gnueabi-gcc. I have a simple lib (libmr.so) that has one function void Print(); that prints something to the console. I'm compiling with:
arm-linux-gnueabi-gcc -Wall -shared -o libmr.so mr.c
When inspecting it using file libmr.so everything seems to be good. However when I'm including it with my android app and try to load it, it is as if it doesn't exist. I'm certain it is there, the path is absolutely correct as I tried to load another lib (libmonodroid.so) from the same folder and it worked.
I tried inspecting both libs to find some kind of a difference:
$ objdump -x libmr.so | grep NEEDED
NEEDED libc.so.6
$ objdump -x libmonodroid.so | grep NEEDED
NEEDED libc.so
... (in addition to other libs)
This is the only difference I'm finding between the two. libmonodroid.so loads properly but libmr.so acts as if it doesn't exist. (I'm using dlopen to load a lib)
EDIT:
I built an executable using the same toolchain, gave me a clue:
Static linking with libc: arm-linux-gnueabi-gcc -Wall -o hi source.c -static. Pushed hi to my android devices and executed it with adb. Result: SUCCESS!
Dynamic linking with libc: arm-linux-gnueabi-gcc -Wall -o hi source.c. Result: it's not even there! Meaning ./hi gives /system/bin/sh: ./hi: not found although it's absolutely there.
So, looks like libc is really the culprit? Maybe I need to link dynamically with not libc.so.6 but with libc.so just like libmonodroid.so is doing?
Check this out for anyone having the same problem. Download the ndk, there's a standalone toolchain for building native libs that run on android that you can extract (you won't need the whole ndk).
I was able to run a basic app on ubuntu 15.04 with this Makefile in the same dir as my hi.c:
$ cat hi.c # create hi.c with favorite editor
#include <stdio.h>
int main(int argc, char** argv) {
int uid = getuid();
int eid = geteuid();
printf("Hello world\n");
printf("You are uid: %d and eid; %d", uid, eid);
return 0;
}
$ cat Makefile # create two line Makefile
CC=arm-linux-gnueabi-gcc
LDFLAGS=-static
$ make hi # build arm based hi executable file
arm-linux-gnueabi-gcc -static hi.c -o hi
$ file hi # check file type
hi: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=17b65e60cdd32449ac237bfd1b8238bfa1d416a0, not stripped
$ adb push hi /data/local/tmp # copy to droid fon
4403 KB/s (593252 bytes in 0.131s)
$ adb shell /data/local/tmp/hi # run hi executable
adb shell /data/local/tmp/hi
Hello world
You are uid: 2000 and eid; 2000
$ uname -a
Linux lenny 3.19.0-28-generic #30-Ubuntu SMP Mon Aug 31 15:52:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Note that I do not have any NDK installed.
How can I build OpenSSL for Android ARM v7 (using Android NDK) on Win32?
Until the OpenSSL's wiki and setenv-android.sh are updated accordingly, I'll publish the recipe here. The required fixes to the process are:
Update setenv-android.sh to support Windows.
Update PATH to use Android NDK's (mingw) GNU make (rather than Cygwin's).
Invoke make with a Windows-style path to Cygwin's perl.
This recipe will be a strange hybrid of Cygwin and mingw (since Android NDK gcc toolchains for win32 are mingw). I'm assuming a Windows x86_64 build of the Android NDK unpacked into c:\android-ndk-r9d, and that you wish to use a gcc 4.8 toolchain.
Install Android NDK (duh!).
Install Cygwin -- make sure to include perl
Start Cygwin shell as an administrator to make sure native symlinks will work.
Within the console, run the following script to set the variables:
export \
CYGWIN=winsymlinks:native \
ANDROID_API=android-14 \
ANDROID_DEV=c:/android-ndk-r9d/platforms/android-14/arch-arm/usr \
PATH=/cygdrive/c/android-ndk-r9d/prebuilt/windows-x86_64/bin:/cygdrive/c/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin:$PATH \
MACHINE=armv7 \
SYSTEM=android \
ARCH=arm \
CROSS_COMPILE=arm-linux-androideabi-
Now, unpack openssl:
tar xzfv openssl-1.0.1i.tar.gz (or whatever your tarball is)
cd openssl-1.0.1i (or whatever your version is)
Make sure you have actual native Win32 (!) symlinks in include/openssl:
cmd /c "dir include\openssl"
You should see something like:
13-Aug-14 05:59 PM <SYMLINK> aes.h [..\..\crypto\aes\aes.h]
13-Aug-14 05:59 PM <SYMLINK> asn1.h [..\..\crypto\asn1\asn1.h]
(etc.)
Now it's time to configure:
./config shared -no-ssl2 -no-ssl3 -no-comp -no-hw -no-engine --openssldir=/foo/bar
Ignore the failure to build (due to failure to find perl). We'll rectify this right away. Do this:
make PERL=$(cygpath -w $(which perl))
Now wait for a few minutes until it builds, and presto, you have your libcrypto.so etc.
Just a couple of comments on my experience with this:
Executing this statement:
PERL=$(cygpath -w $(which perl))
in the cygwin shell allows the shell to interpret the backslashes as escape characters and the build process chokes. To solve this I did the following:
$ echo $(cygpath -w $(which perl))
which produced the windows formatted path to the perl executable:
C:\cygwin64\bin\perl
Then I added this line to the export shown above:
PERL=c:/cygwin64/bin/perl \
There are other ways of doing this, but it worked and headed off the problem with the ./config statement documented above (not finding perl).
Second issue was the -no- statements. After running the configure, the script reports that you'll have to run make depend. I wanted to exclude MD5 (i.e. -no-md5) and when I did the make depend, it errored out with a report that MD5 was disabled. Uhhh, yes, that was kind of the idea, but I just won't use MD5 hashes. I did use the -no-ssl2 and didn't get any complaints after the make depend.
Third issue and this is a mystery. The build broke on compiling crypto because it could not find a symbol that is supposed to be defined in /crypto/objects/obj_xref.h. When I looked at the file, it was empty. Something in the perl script I suppose, but no time to debug right now, since I'm at proof of concept phase. I placed a copy from a patch that I picked up at https://github.com/devpack/openssl-android
After that, my build ran to completion. I've done no testing with this and it is not a trustworthy solution, but it did compile and produce the static libraries that I need for proof of concept for my client.
Just as an update, my shared library built with these libraries loaded fine on my target.
Has anybody out there successfully cross-compiled librtmp for the Android platform? I know that the rtmpdump android download has librtmp.so included, but I think I need librtmp.a also (I am trying to cross-compile ffmpeg with librtmp support).
Anybody had any luck with this? It's driving me bonkers....
Ta
Dan
have a look here http://stream-recorder.com/forum/rtmpdump-build-android-t13466.html
and I've put a howto on my github here https://github.com/S74ck3r/rtmpdump/blob/master/readme-howto-build.txt
hope that helps
Richard
I* just successfully built librtmp for Android using the Guardian Project's OpenSSL repo. I documented my steps here along with preserved build scripts.
In a nutshell, build OpenSSL per GuardianProject's directions, then run the following script in rtmpdump/librtmp:
#build_librtmp_for_android.sh
NDK=/path/to/android-ndk-r9c
SYSROOT=$NDK/platforms/android-19/arch-arm/
TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64
OPENSSL_DIR=/path/to/openssl-android/
# Note: Change the above variables for your system. Also ensure you've built openssl-android
function build_one
{
set -e
make clean
ln -s ${SYSROOT}usr/lib/crtbegin_so.o
ln -s ${SYSROOT}usr/lib/crtend_so.o
export XLDFLAGS="$ADDI_LDFLAGS -L${OPENSSL_DIR}libs/armeabi -L${SYSROOT}usr/lib "
export CROSS_COMPILE=$TOOLCHAIN/bin/arm-linux-androideabi-
export XCFLAGS="${ADDI_CFLAGS} -I${OPENSSL_DIR}include -isysroot ${SYSROOT}"
export INC="-I${SYSROOT}"
make prefix=\"${PREFIX}\" OPT= install
}
CPU=arm
PREFIX=$(pwd)/android/$CPU
ADDI_CFLAGS="-marm"
build_one
*with the incredible help of my pal Chris.
I've build the Android NDK toolchain manually. Everything works except when I use the compiler it can't find basic STL stuff like . So it can't compile code containing STL because it doesn't know where to look for the headers by default. I've never had this problem before using a custom or prebuilt toolchain. However if I manually add the include directories like
-I$(NDK_TOOLCHAIN)/arm-linux-androideabi/include/c++/4.6/
Then it works just fine. It is a pain to add every important dir manually (there is more than this one). Surely something broken in the process.
These are the steps I followed to get it build:
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl
Download NDK
Untar NDK to [SOME_LOCATION], using /opt/ndk/
Set NDK_ROOT=/opt/ndk/
./build/tools/download-toolchain-sources.sh src/
Download MPC 0.9
Move mpc tar to ./src/mpc/
./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) arm-linux-androideabi-4.6
./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) x86-4.6
./build/tools/build-gcc.sh --gmp-version=4.3.2 --mpc-version=0.9 --mpfr-version=2.4.2 --binutils-version=2.21 $(pwd)/src $(pwd) mipsel-linux-android-4.6
All the STL files exist in the proper location. All the headers and compiled libraries for each version if I build a STANDALONE toolchain after using as reference these custom built toolchains.
==
UPDATE
Forcing gcc to spit out its include search paths:
echo "#include <bogus.h> int main(){}" > t.c; /opt/android-9_arm/bin/arm-linux-androideabi-gcc -v t.c; rm t.c
This contains a search path under includes:
/opt/android-9_arm/bin/../lib/gcc/arm-linux-androideabi/4.6.x-google/../../../../arm-linux-androideabi/include
At that location is indeed the following ./cxx/4.6/STL_HEADERS
Comparing the output with a NDK build from google does indeed differ in serious spots. The real question is now how do I guarantee my custom build of GCC points to the appropriate G++ STL header location.
It turned out to be a bug in make-standalone-toolchain.sh. The fix was:
mv $NDK_TOOLCHAIN/arm-linux-androideabi/include/c++/4.6 $NDK_TOOLCHAIN/arm-linux-androideabi/include/c++/4.6.x-google
That fixed it for the most part. However now that the ndkr8b has released with official GCC 4.6 support this bug stills exists (as of july 25 2012). More details on some bugs related to the standalone toolchain (http://code.google.com/p/android/issues/detail?id=35279).