Develop Reference

Compiling gentoo-bionic on a x86_64 linux machine

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.

Cross compiling GCC with newlib for ARM: how to specify GCC options like -march?

I've compiled GCC along with newlib on Mac OS X for ARM targets. However, libc.a was compiled with -fshort-enums, and I don't want that because when I compile stuff for ARM, I use -fno-short-enums. This conflicts, of course:
ld: warning: /var/folders/9m/2wnjp9zd71x13cpdpf16y_4r0000gn/T//ccQuEnp6.o uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail
Every time I try to run a "Hello, World!" executable, it segfaults. Could this be the reason?
Here's the command I used to compile hello.c:
arm-eabi-gcc \
hello.c -o hello \
/Users/user/gcc-arm-install/arm-eabi/lib/crt0.o \
/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0/crtbegin.o \
/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0/crti.o \
/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0/crtn.o \
/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0/crtend.o \
-v -nostdinc -nostdlib -static \
-march=armv7-a -mno-thumb-interwork -marm -mfpu=neon -mfloat-abi=softfp -fpic \
-ffunction-sections -fno-short-enums -fno-rtti -fno-exceptions \
-I/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0/include \
-I/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0/include-fixed \
-I/Users/user/gcc-arm-install/arm-eabi/include \
-I/Users/user/gcc-arm-install/arm-eabi/sys-include \
-L/Users/user/gcc-arm-install/arm-eabi/lib \
-L/Users/user/gcc-arm-install/lib/gcc/arm-eabi/4.7.0 \
-lm -lc -lgcc
Update:
Okay, I think I've narrowed the problem down to the combination of newlib's libc and the startup files (crt0.o). I tried compiling a test app with GCC 4.7.0 using libc.a and startup files from the Android NDK, and that worked on the phone when compiled static. In fact, it worked even though ld complained again about libgcc using "variable-size enums" (i.e., not compiled with -fno-short-enums like everything else). So, my hypothesis about -fno-short-enums being the culprit in my earlier crashing binaries was incorrect.
Here's what's working:
Binutils and GCC 4.7.0 compiled from source for target "arm-linux-eabi." I configured GCC using --with-newlib (newlib and libgloss in GCC's source tree). So, GCC was actually built with newlib and installed along with newlib, and it generates working binaries as long as I don't actually link with newlib's libc. At present, I must use libc from the Andoid NDK and its startup files instead.
My compile script looks something like this. The include and library paths point to the NDK includes and libc:
NDK_PATH="/Users/user/SOURCE/android-ndk-r8/platforms/android-9/arch-arm"
CFLAGS="-nostdinc -nostdlib -static -fno-short-enums -lc -lgcc -lc"
gcc $NDK_PATH/usr/lib/crtbegin_static.o \
hello.c -o hello $CFLAGS \
$NDK_PATH/usr/lib/crtend_android.o
I still want to get binaries compiled statically with newlib's libc working. Back to shell scripting...

For work I cross-build for the Cortex-M3 platform, and I also use newlib. The following links may be helpful for you:
http://frank.harvard.edu/~coldwell/toolchain/
http://www.microbuilder.eu/Tutorials/SoftwareDevelopment/BuildingGCCToolchain.aspx
Although the following link is specific to Cortex-M3, it may provide some insight for you, I used it to script my toolchain build:
http://www.johannes-bauer.com/mcus/cortex/?menuid=5
Your newlib may have been miscompiled (maybe with the host compiler? Highly unlikely since it links, but hey it's possible).

I think you could first write a shell script to choose the work env, like you will work under gcc or arm-gcc. in this script, you could make an alternative lib link to different lib you want, like if you login and choose gcc, the lib file will be normal libc and if you choose arm-gcc, the lib will be the different one

How to configure gcc to compile for android?

I've read in the gcc documentation that it supports building android binaries with the -mandroid and -mbionic switches. First I tried it with the native gcc built from svn. Result:
dancsi#dancsi-VirtualBox:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../source/configure --enable-threads --disable-nls
Thread model: posix
gcc version 4.7.0 20110611 (experimental) (GCC)
dancsi#dancsi-VirtualBox:~$ g++ test.cpp -mandroid -o test.out
dancsi#dancsi-VirtualBox:~$ file test.out
test.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
Basically, it failed. Next, I tried to compile the same gcc sources with target=arm-linux-androideabi, (without defining sysroot,...), and it passed the configuration, but failed to build saying pthread.h is not found:
In file included from ../.././gcc/gthr-default.h:1:0,
from ../../../combined/libgcc/../gcc/gthr.h:160,
from ../../../combined/libgcc/../gcc/unwind-dw2.c:37:
../../../combined/libgcc/../gcc/gthr-posix.h:41:21: fatal error: pthread.h: No such file or directory
compilation terminated.
So, does anybody have the instructions for how to use gcc to build android binaries (I don't want to use code sourcery or android-ndk)?
EDIT:
my configure options
configure --target=arm-linux-android --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libssp --disable-libgomp --disable-nls --enable-languages=c,c++,java

I had exactly the same problem as described by dancsi while trying to compile my own cross compilation tool chains for Android (I wanted to build a 32 bit variant of them so I don't need to buy a 64 bit PC or do my android stuff in a VM).
I am using the tool chain sources from the official AOSP tool chain repo:
repo init -u https://android.googlesource.com/toolchain/manifest
The solution is to use the following 2 extra configure options: --with-headers and --with-libs. I've got this solution by reading the following file: [android-toolchain-repo]/build/README:
The other way is to specify the headers and libraries with --with-headers and
--with-libs separately. If you configure your tree with a prefix. The headers
and libraries will be copied to the install directory specified by the prefix.
For the values of those 2 extra parameters I used [android-src-repo]/prebuilts/ndk/8/platforms/android-14/arch-arm/usr/lib and [android-src-repo]/prebuilts/ndk/8/platforms/android-14/arch-arm/usr/include. [android-src-repo] is referring to my repo checkout of the base AOSP sources (in my case I am on the android-4.2.2_r1 branch of it).
The end-result of the two configure statements I need are the following:
./configure --target=arm-eabi --host=i686-linux-gnu --build=i686-linux-gnu --disable-gold \
--with-gcc-version=4.6 --with-binutils-version=2.21 --with-gmp-version=4.2.4 --with-mpfr-version=2.4.1 \
--with-gdb-version=7.3.x --with-gold-version=2.21 --prefix=/tmp/toolchain --disable-multilib \
--with-libs=/home/boeboe/android-src/prebuilts/ndk/8/platforms/android-14/arch-arm/usr/lib \
--with-headers=/home/boeboe/android-src/prebuilts/ndk/8/platforms/android-14/arch-arm/usr/include \
--program-transform-name='s&^&arm-eabi-&' --with-arch=armv5te --disable-option-checking
./configure --target=arm-linux-androideabi --host=i686-linux-gnu --build=i686-linux-gnu --enable-gold \
--with-gcc-version=4.6 --with-binutils-version=2.21 --with-gmp-version=4.2.4 --with-mpfr-version=2.4.1 \
--with-gdb-version=7.3.x --with-gold-version=2.21 --prefix=/tmp/toolchain \
--with-libs=/home/boeboe/android-src/prebuilts/ndk/8/platforms/android-14/arch-arm/usr/lib \
--with-headers=/home/boeboe/android-src/prebuilts/ndk/8/platforms/android-14/arch-arm/usr/include \
--program-transform-name='s&^&arm-linux-androideabi-&' --disable-option-checking
Notice the extra --disable-option-checking argument which was necessary for configure to accept all arguments!
This long list of arguments was constructed by checking the original configure arguments passed for the default 64 bit version of the 4.6 gcc toolchain. This can be checked in the SOURCES files available in [android-src-repo]/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6 and [android-src-repo]/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6.
In the same files, git tags can be found, so I also checkout those specific version in my [android-toolchain-repo]. For the extra modules needed by gcc, like gmp/mpfr/gdb..., I extracted the correct versions of the tar-balls available in [android-toolchain-repo]/gmp|mpfr|gdb. This was the easiest way I could find out, for my original configure statement to be able to pick up those modules.
The same technique as described above also allowed me to compile a 32 bit variant of the latest gcc 4.7 tool chain (currently being used on the MAIN branch of AOSP). The configure options were of course different in this case.

In file included from ../.././gcc/gthr-default.h:1:0,
from /mnt/network/source/gcc/libgcc/../gcc/gthr.h:160,
from /mnt/network/source/gcc/libgcc/../gcc/unwind-dw2.c:37:
/mnt/network/source/gcc/libgcc/../gcc/gthr-posix.h:41:21: fatal error: pthread.h: No such file or directory
compilation terminated.
make[2]: *** [unwind-dw2.o] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
I'm getting the same error as you, but I'm not compiling for Android. I'm trying to build w64-mingw32 compiler.
AR=x86_64-w64-mingw32-ar RANLIB=x86_64-w64-mingw32-ranlib
../gcc-4.5.1/configure --prefix=/tools \
--with-local-prefix=/tools --enable-clocale=gnu \
--enable-shared --enable-threads=posix \
--enable-__cxa_atexit --enable-languages=c,c++ \
--disable-libstdcxx-pch --disable-multilib \
--disable-bootstrap --disable-libgomp \
--without-ppl --without-cloog --build=$MACHTYPE --host=$MACHTYPE --target=x86_64-w64-mingw32
My response is so you know its not just Android, the trouble is more general then just building for the ARM architecture.
I think its a c++ issue, cause I had/have no trouble with building a c compiler alone.

browser plugin for default android browser

I would like to develop a plugin for the default android browser which would specify the category of sites in the google search result. The android browser dont explicitly show plugin architecture. I would like to know how that can be done and any reference materials related to that.
Thanks,

I recently tried to make an android plugin and found many questions on SO but not many detailed answers, so I'd thought I'd share my research here even though the question is quite old now. I'm not sure if a plugin is really what you want to do here since you could probably use google's JSON/ATOM Custom Search API and parse that, but nonetheless I give details on how to get plugins working on Android. I hope it is useful for others.
If you look here: PluginManager.java you will see the following lines:
// Only plugin matches one of the signatures in the list can be loaded
// inside the WebView process
private static final String SIGNATURE_1 = "308204c5..."
The signature used here is the one for the Adobe Flash plugin (support for which has now been dropped by Adobe.)
and further down here you will see:
if (SystemProperties.getBoolean("ro.secure", false)) {
boolean signatureMatch = false;
for (Signature signature : signatures) {
for (int i = 0; i < SIGNATURES.length; i++) {
if (SIGNATURES[i].equals(signature)) {
signatureMatch = true;
break;
}
}
}
if (!signatureMatch) {
return false;
}
}
This means that if ro.secure=0 then it won't check the signatures - it would only allow the flash plugin otherwise.
ro.secure is a build property that you can set if you have root privaleges for your device or you have a dev build (type adb shell getprop ro.secure to find out what you have). You can research how to change this if necessary. I was using a Qualcomm Snapdragon MDP8960 which is development board which had ro.secure=0 already. To get your plugin signature included in android you'll have to talk to someone in charge - not sure how feasible this is at present.
Now to write a plugin - you can find an example called SampleBrowserPlugin in the android sourcetree (make sure you have a 64 bit linux machine if you want to build it - type make SampleBrowserPlugin from the source tree root. You might need to set up the build configuration first using lunch and you can find instructions on the android source tree site)
I actually grabbed the source I needed from android source on github and made an NDK build of the source as I am more familiar with how to do this than modifying the android build scripts. It will also be a lot faster than downloading the whole android tree - you can see what to download by looking at what is included in Android.mk (see below).
Basically, I pulled the shared object libraries that I needed from the device to make sure my plugin would be compatible. They were in /system/lib on my device: (e.g. type adb pull /system/libnativehelper.so etc from the directory where you want them stored)
get the following:
libnativehelper.so
libandroid.so
libutils.so
libcutils.so
libEGL.so
libGLESv2.so
libskia.so
Put them where SO_LIB_PATH points to in Android.mk (see below and change Path as necessary).
Then after installing the NDK sdk you should be able to use the following build script - don't need a 64 bit machine - (you can install winbash, use cygwin, or a linux virtual machine e.g. Oracle VM VirtualBox:
(Place these files in C:/Path/BrowserPlugin/jni/ and make sure the ndk-build command is on your path)
(if you're on linux remove the .cmd from ndk-build.cmd)
build.sh:
#!/bin/bash
echo -e "Mode\t\t: Debug"
OPTIM=debug
### ---------------- Generic Build Command ----------------
# run NDK build
ndk-build.cmd \
-d \
-B \
NDK_DEBUG=1 \
NDK_PROJECT_PATH=C:/Path/BrowserPlugin/jni \
NDK_APPLICATION_MK=C:/Path/BrowserPlugin/jni/Application.mk \
NDK_MODULE_PATH=C:/Path/BrowserPlugin/jni \
NDK_APP_OUT=C:/Path/BrowserPlugin/jni/Out/ \
APP_BUILD_SCRIPT=C:/Path/BrowserPlugin/jni/Android.mk \
APP_OPTIM=$OPTIM
cp C:/Path/BrowserPlugin/jni/Out/local/armeabi/libsampleplugin.so C:/Path/BrowserPlugin/libs/armeabi/.
echo "copied libsampleplugin.so into PROJECT_ROOT/libs dir"
Android.mk:
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := \
main.cpp \
PluginObject.cpp \
RenderingThread.cpp \
animation/AnimationPlugin.cpp \
animation/AnimationThread.cpp \
audio/AudioPlugin.cpp \
background/BackgroundPlugin.cpp \
form/FormPlugin.cpp \
navigation/NavigationPlugin.cpp \
paint/PaintPlugin.cpp \
video/VideoPlugin.cpp \
jni-bridge.cpp \
WEBCORE_PATH := C:/Path/AndroidBrowserPlugin/webkit/Source/WebCore
LOCAL_C_INCLUDES += \
$(JNI_H_INCLUDE) \
$(LOCAL_PATH) \
$(LOCAL_PATH)/animation \
$(LOCAL_PATH)/audio \
$(LOCAL_PATH)/background \
$(LOCAL_PATH)/form \
$(LOCAL_PATH)/navigation \
$(LOCAL_PATH)/paint \
$(LOCAL_PATH)/video \
$(WEBCORE_PATH)/bridge \
$(WEBCORE_PATH)/plugins \
C:/Path/AndroidBrowserPlugin/webkit/Source/WebKit/android/JavaVM \
C:/Path/AndroidBrowserPlugin/webkit/Source/WebKit/android/plugins \
C:/Path/AndroidBrowserPlugin/platform_external_skia/include/core \
C:/Path/AndroidBrowserPlugin/frameworks_native/include \
C:/Path/AndroidBrowserPlugin/frameworks_native/libs \
C:/Path/AndroidBrowserPlugin/frameworks_native/opengl/libs \
C:/Path/AndroidBrowserPlugin/platform_system_core/include \
C:/Path/AndroidBrowserPlugin/frameworks_native/opengl/include \
C:/Users/user/android-ndk-r8c/platforms/android-14/arch-arm/usr/include \
C:/Path/AndroidBrowserPlugin/BrowserPlugin/jni/libs/armeabi \
C:/Path/AndroidBrowserPlugin/platform_bionic \
C:/Path/AndroidBrowserPlugin/platform_bionic/libc/private \
C:/Path/AndroidBrowserPlugin/platform_hardware_libhardware/include
SO_LIB_PATH := C:/Path/AndroidBrowserPlugin/libs_qualcomm_MDP8960
LOCAL_LDLIBS := \
-L$(SO_LIB_PATH)/ -lnativehelper -landroid -lutils -lcutils -lEGL -lGLESv2 -lskia
LOCAL_CFLAGS += -fvisibility=hidden
LOCAL_CFLAGS += -DHAVE_PTHREADS -DANDROID
LOCAL_MODULE:= libsampleplugin
LOCAL_MODULE_TAGS := optional
include $(BUILD_SHARED_LIBRARY)
Application.mk:
# =============================================================================
#
# Main build file defining the project modules and their global variables.
#
# =============================================================================
# Don't remove this - mandatory
APP_PROJECT_PATH := $(call my-dir)
# The only STL implementation currently working with exceptions
APP_STL := gnustl_static
# Don't optimize for better debugging
APP_OPTIM := debug
You may also need some header files (e.g. JNIHelp.h) which you can place e.g. in the root where you are doing the ndk build BrowserPlugin/jni/.
Hopefully bash build.sh should build your libsampleplugin.so which the build script copies into the app directory. You can then e.g. import the project into eclipse and build the app. Install it on the device, then e.g. use WAMP server to host the following file:
index.html:
<!DOCTYPE html>
<html>
<head>
<title>Test Plugin</title>
</head>
<body>
<object type="application/x-testbrowserplugin" height=50 width=250 id="testPlugin">
<param name="DrawingModel" value="Bitmap" />
<param name="PluginType" value="Form" />
</object>
</body>
</html>
run ipconfig from your host machine to get the IP address e.g. 192.168.x.x
Then point your device browser to e.g. http://192.168.x.x/ and voila you should see a form plugin.
I couldn't get the animation plugins to work properly, and the form plugin didn't work fully, but at least the plugin was recognised and loaded ok.
Now, you can write a webkit NPAPI plugin to do what you like either using the sample plugin browser as a guide, or other internet resources.

This is actually quite interesting topic which was discussed recently during blackhat 2014 (FakeID) but in a bit different context. They've found security bug in signature validation.
In your case there are two helpful links :
1) http://androidxref.com/4.3_r2.1/xref/frameworks/base/tests/BrowserTestPlugin/ This is the newest sample of writing webkit plugins. Try to build it - it will require to have webkit external statically linked otherwise you will get ‘ fatal error: android_npapi.h: No such file or directory’
2) http://androidxref.com/2.2.3/xref/development/samples/BrowserPlugin/ This is older sample but it has wider description of "how to build" browser plugin
Use combination of both link to start your plugin development
However this doesn't solve signature check problem. Even if the plugin is recognised it won't be allowed to run. I'm not sure what is the process with google to do browser plugin development

compiling synamic arm code

I'm building some common gnu/linux console utilities for my Android phone but so far I have only been able to build them statically, with quite a size penalty. Can someone walk me through the steps for synamic compiles using shared libraries?
Here's the script(s) I'm using for configuration:
./configure --host=arm-none-linux-gnueabi \
CC="arm-none-linux-gnueabi-gcc" \
CROSS_COMPILE="arm-none-linux-gnueabi-" \
CFLAGS=" -static $_XXFLAGS" \
for shared:
./configure --host=arm-none-linux-gnueabi \
CC="arm-none-linux-gnueabi-gcc" \
CROSS_COMPILE="arm-none-linux-gnueabi-" \
--enable-shared=yes --enable-static=no
Do I need to make the libs on my android phone avaiable
to my cross-compiler? Google isn't helping me here.

You would have to provide the location for the shared libraries that you want to link against. Please post the error that you're getting for a better answer, but take a look at my answer to
install 64-bit glib2 on 32-bit system for cross-compiling
You should just need to add the right -L and -Wl,-rpath-link to the CFLAGS variable when you're running configure.