[C/C++] Fail to build Android with g++/gcc-4.6 (Ubuntu-11.10)

[ g++ issue ]

g++-4.4 / g++-4.5 doesn’t detect following case, but, g++-4.6 does.

< a.cpp >
---------

class P {
public:
    void a();
};

class A : public P {
public:
    void p();
};

void
P::a() {
    // 'const' quailifier' is discard here!
    static_cast<const A*>(this)->p();
}

void
A::p() {
    ;
}

int
main() {
    return 0;
}

=================== Test ======================
$ g++-4.5 a.cpp   <= OK.
$ g++-4.6 a.cpp
a.cpp: In member function ‘void P::a()’:
a.cpp:13:33: error: passing ‘const A’ as ‘this’ argument of ‘void A::p()’ discards qualifiers [-fpermissive]

The problem is some of Android codes still have above bugs in its code – ex. frameworks/base/libs/utils/RefBase.cpp.
So, even if Android source code was successfully compiled at g++-4.4 or g++4.5, it may be failed at g++-4.6 (for example, upgrading host OS)

[ cc/gcc issue ]

Compiling with gcc-4.6 raises following warings.

<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]

In some component which uses ‘-Werror’ option, this warning stops compilation.

[ Conclusion ]

So, you would better to use gcc/g++-4.4 instead of 4.6 when building Android, until above issues are resolved on Android baseline.
(ex. Ubuntu 11.10 as an Android host OS.)

[Android] Developing Android-native-library on 64bit build machine

Most Android device is 32bit machine. So, many application assumes that host machine is 32bit system.
And in general, there is no difference developing Android-natvie-library between 64bit and 32bit build machine.

But, here is usual step for developing Android-native-library.
(1) Developing and verifying code at build machine.
(2) Porting to NDK build system.

Most developers turns on full-warning-option at compile to detect bugs at early stage.
But, building and verifying codes assuming 32bit host machine at 64bit machine always issues type casting warning due to different type size.
Especially, between pointer and integer.

For example, many Android JAVA application uses intjint – as a type to contain native pointer with assumption of 32bit-host-system.
Building this code at 64bit build system to verify code issues type casting warning, even if code itself is built perfectly at NDK build system.
And it is worse that this code doesn’t work at 64bit Android host machine, even though it is not popular.

To reduce this warnings (for easy-verifying of library code at build machine), in my opinion, using longjlong – instead of jint as a type for containing native pointer is better unless memory space is extremely critical.
And to make compiler be happy, using macro can be a good choice.
Here is example of macro for type-casting between pointer and integer – jlong.
(This sample works well without warning at 32bit/64bit build/host system).

#define ptr2jlong(v) ((jlong)((intptr_t)(v)))
#define jlong2ptr(v) ((void*)((intptr_t)(v)))

This is just simple example for portability issues.
Making portable code is always very difficult…

[Android] Creating minimum set of Android (Kernel + adbd + ueventd) for Android kernel test.

To test Android kernel, keeping minimum number of user space process is very useful.
Actually, ‘adbd’ and ‘ueventd’ is enough on Android.
Here is the way how to make device have only minimum user space processes – adbd and ueventd.
Followings are file structure of ramdisk image.

[ Create ramdisk ]

let’s make following directory structure in ramdisk.

/bin -> sbin
/sbin -+- busybox
       +- adbd
       +- ueventd -> ../init
       +- <...> -> busybox
/init
/init.rc
/default.prop

All are same with default android except that busybox is in /sbin and /bin is symbolic link to /sbin.
Let’s look into one by one.

/init : same binary with default Android.
/bin : symbolic link to /sbin.
/default.prop : same with default Android. – adb and debugging is enabled.
/sbin/busybox : statically linked busybox.
/sbin/… : tools (symbolic link to busybox). Ex, sh -> busybox, ls -> busybox.
/sbin/adbd :
Modified adbd. Original adbd uses /system/bin/sh as its terminal shell. But, this one uses /bin/sh.
To do this, value of SHELL_COMMAND at system/core/adb/service.c should be modified.
/init.rc :
Simplified one. Only adbd and ueventd is started.
One important note is, “DO NOT make empty section(ex. on fs)!”. This will lead init process to error and system will restarted again and again.
Here is sample.

on early-init
    start ueventd

on init
    sysclktz 0
    export PATH /bin:/sbin:

#on fs

#on post-fs

#on post-fs-data

on boot
   start adbd

## Daemon processes to be run by init.
##
service ueventd /sbin/ueventd

service adbd /sbin/adbd

[ Make ramdisk image ]

Let’s assume that current working directory is ramdisk directory.

find . | cpio -o -H newc | gzip > newramdisk.gz

This newly generated gzip file can be renamed directly to ramdisk.img.

[ Make boot image ]

mkbootimg tool is used. This can be easily found at out/host/<arch>/bin after building android from source.

mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel <zImage file> --ramdisk <ramdisk image> -o newboot

[ Verify ]

After flashing newly generated boot image, reboot device.
The only respond that device can do, is done at boot-loader stage. After that device doesn’t anything.
After waiting some moments, try adb device. Then host PC can find the device and adb shell can be used.
Type adb shell ps. Then, you can check that only three user space process are running – init, adbd and ueventd.

[ Debugging ]

Except for kernel, adbd and init may be required to be modified (As mentioned above, modified adbd is used.). Printing log is very helpful for debugging and using framebuffer console is simple way to do this.
Here is the step (ex. adbd).

* comment out xxxx in init.c
=> this removes /dev/console (framebuffer console)
* modify start_logging() and start_device_log() in adb.c.
=> use /dev/console as stdout and stderr file.

Now, log message of adbd will be shown on the framebuffer (that is, displayed at the panel.)

[ Something more ]

You may build your own Linux environment on the device by building file system and installing libraries etc.
In my case, I set up tools for development – ex. glibc, gcc, binutils etc, and compiled LTP(Linux Test Project) to test kernel.
Enjoy your minimum Android environment :-).

[ARM] Multi-core optimzation test…

This test is done under following environment.

x86 :

intel Core(TM)2 Duo T9400 2.53Mhz
GCC-4.4.5

ARM :

OMAP4430 (Cortax-A9)
Android NDK platform 9

Test code.

/*
 * Test Configuration
 */
#define _ARRSZ    1024*1024*8

static int _arr[_ARRSZ];

static void
_init() {
    int i;
    for (i = 0; i < _ARRSZ; i++)
        _arr[i] = i;
}

static unsigned long long
_utime() {
    struct timeval tv;
    if (gettimeofday(&tv, NULL))
        assert(0);
    return (unsigned long long)(tv.tv_sec * 1000000)
        + (unsigned long long)tv.tv_usec;
}

#define _test_arraycopy_pre()               \
    int  i;                                 \
    unsigned long long ut;                  \
    int* ia = malloc(_ARRSZ * sizeof(*ia));

#define _test_arraycopy_post()              \
    free(ia);

#define _operation()            \
    do {                        \
        ia[i] = _arr[i];        \
    } while (0)

static void*
_test_arraycopy_worker(void* arg) {
    int     i;
    int*    ia = arg;
    for (i = (_ARRSZ / 2); i < _ARRSZ; i++)
        _operation();
    return NULL;
}

static unsigned long long
_test_arraycopy_sc() {
    _test_arraycopy_pre();

    ut = _utime();
    for (i = 0; i < _ARRSZ; i++)
        _operation();
    ut = _utime() - ut;

    _test_arraycopy_post();

    return ut;
}

static unsigned long long
_test_arraycopy_dc() {
    pthread_t thd;
    void*     ret;
    _test_arraycopy_pre();

    ut = _utime();
    if (pthread_create(&thd,
               NULL,
               &_test_arraycopy_worker,
               (void*)ia))
        assert(0);

    for (i = 0; i < (_ARRSZ / 2); i++)
        _operation();

    if (pthread_join(thd, &ret))
        assert(0);

    ut = _utime() - ut;

    _test_arraycopy_post();

    return ut;
}

#undef _test_arraycopy_pre
#undef _test_arraycopy_post

int
main(int argc, char* argv[]) {
    _init();
    printf(">> SC : %lld ", _test_arraycopy_sc());
    printf(">> DC : %lld\n", _test_arraycopy_dc());
    return 0;
}

[Test 1]
x86

>> SC : 59346 >> DC : 38566
>> SC : 59195 >> DC : 39028
>> SC : 49529 >> DC : 38160
>> SC : 49722 >> DC : 38457
>> SC : 49952 >> DC : 37457

ARM

>> SC : 102295 >> DC : 94147
>> SC : 102264 >> DC : 94025
>> SC : 102173 >> DC : 94116
>> SC : 102172 >> DC : 94116
>> SC : 102325 >> DC : 94177

Change ‘_operation’ macro to as follows

#define _operation()                                    \
    do {                                                \
        if (i > _ARRSZ / 2)                             \
            ia[i] = (_arr[i] & 0xff) << 8 ^ _arr[i];    \
        else                                            \
            ia[i] = (_arr[i] & 0xff) << 16 ^ _arr[i];   \
    } while (0)                                         \

[Test 2]
x86

>> SC : 60696 >> DC : 40523
>> SC : 56907 >> DC : 45355
>> SC : 55066 >> DC : 42329
>> SC : 54931 >> DC : 40651
>> SC : 57022 >> DC : 41879

ARM

>> SC : 164514 >> DC : 112671
>> SC : 163971 >> DC : 112854
>> SC : 164521 >> DC : 112976
>> SC : 163940 >> DC : 112732
>> SC : 164245 >> DC : 112671

Interesting result, isn’t it?
For heavily-memory-accessing-code (Test 1), ARM does not show good statistics for multi-core (in this case, dual-core) optimization.
But, if not (Test 2), optimization shows quite good results.
And, x86 seems to handle memory accessing from multi-core, quite well.

So, developers should consider ARM’s characteristic when optimize codes for multi-core.
(I’m sure that ARM will improve this someday! :-) )

* Things to consider regarding this kind of optimization *
Cache, Cache coherence, Memory Controller, Bus etc…

[ Test for later version of ARM (ex Cortax-A15) will be listed continuously… ]

[Android] Managing service…

Service
——-
init process 는 다음을 통해서 각종 service를 control함.

SIGCHLD signal handler를 정의해서, service의 상태를 파악함
service가 죽는 경우 SIGCHLD signal이 날아오고, 이 signal로 어떤 service가 죽었는지/시작했는지 파악하고, 각 service의 flag에 따라서 다음 행동 (해당 service를 다시 시작하거나, system을 restart하거나 (critical service))을 결정함.
[property_service.c] ‘/dev/socket/property_service’ socket을 열고 message를 기다림 (PROP_SERVICE_NAME).
‘property_set(…)’ interface를 통해서, property_service socket에 message가 써지고, init process의 property service부분에서 이 message를 handling함.
‘ctl.start/stop/restart’ 는 source code에 hard-coded된 특수한 message로, 해당 이름의 service를 control한다.

잊어먹지 않기 위해서 일단 기록해 둠….

[Android] Handling kernel device uevent in userspace.

⚫ ueventd
    ⚬ ueventd creates and 'poll' netlink socket.
        ueventd_main [init/ueventd.c]

    ⚬ read kernel event message -> parse -> handle
        handle_device_event [init/devices.c]
            -> device_changed [init/init.c]
                -> queue_device_triggers [init/init_parser.c]
                            |
            +---------------+
            |
            v
        : search action list to know what to do for this event.
          searching action which name is device-added/removed-[device node].
          [device node] is from 'DEVPATH' variable of uevent message.

    ⚬ action list : list declared at [init_parser.c]
        • builtin action (added by 'queue_builtin_action [init/init_parser.c]')
            ex. property_init, wait_for_coldboot_done etc.
        • from script (added by 'parse_action [init/init_parser.c]')
            section "on device-added-[device path] / on device-removed-[device path]"
            ex.
                [init.rc]
                on device-added-/dev/block/mmcblk0p18
                    exec /system/bin/sh /system/bin/hello_mmc.sh

⚫ other daemons (ex usbd)
    ⚬ create and 'poll' netlink socket.

[Android][GNU] establishing gnu system root on android devices

This article is to describe summary and some important points to establish gnu system root on android devices based on my experience.

Notation
    [] : version used.

===============
Introduction
===============
    Now a days, performance of Android mobile device is much like PC.
    So, why don't you use Android device just like linux desktop?
    As a first step, here is summary to construct gnu system root on Android device.

==============
Setup Sequence
==============
    Installing cross compiling tools
    ----------------------------------------------------------------------
        *** NOTE ****************************************************************
        *    Followings are not tested because I just used built Sourcery g++.  *
        *    [ Codesourcery 2007q3-53 ]                                         *
        *************************************************************************
        * Reference : http://frank.harvard.edu/~coldwell/toolchain/
        * Build GNU binutils
            - Using '--disable-nls' option is recommended (to reduce compile time and dependency.
        * Install Linux Kernel Headers
            - Latest Sourcery g++(2010.09-50) supports only at-least-2.6.16-target-kernel.
        * Build GLIBC headers
        * Build GCC for headers:
            - Using '--disable-nls --without-headers' is recommended.
            - example : configure option of GCC in Codesourcery 2007q3-53
                /vobs/linuxjava/cs_toolchain/mycstc/cs_build_dir/src/gcc-4.2/configure --build=i686-pc-linux-gnu
                  --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
                  --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
                  --enable-languages=c,c++ --enable-shared --enable-symvers=gnu --enable-__cxa_atexit
                  --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q3-53
                  --with-bugurl=https://support.codesourcery.com/GNUToolchain/
                  --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
                  --with-build-sysroot=/vobs/linuxjava/cs_toolchain/mycstc/cs_build_dir/install/arm-none-linux-gnueabi/libc
                  --enable-poison-system-directories
                  --with-build-time-tools=/vobs/linuxjava/cs_toolchain/mycstc/cs_build_dir/install/arm-none-linux-gnueabi/bin
                  --with-build-time-tools=/vobs/linuxjava/cs_toolchain/mycstc/cs_build_dir/install/arm-none-linux-gnueabi/binff
        * Build GLIBC libraries
        * Rebuild GCC using newly-built-GLIBC.

    Construct gnu system root
    -------------------------
        * Environments
            # this directory will be new gnu system root on Android target.
            PREFIX=/data/arm-gnu-sysroot/
            # gnu root directory on target device
            TGNUROOT=/data/gnuroot/
            TARGET=arm-none-linux-gnueabi
            export ARCH=arm
            export CROSS_COMPILE=${TARGET}-
            # set PATH
            PATH=<cross-tools>:$PATH
        * Install headers and GLIBC
            - copy cross-compiled glibc, headers etc to $TROOT except for i686 executables and related files
        * Build GNU binutils [binutils-2.18]
            - ./configure --prefix=${PREFIX} --host=${TARGET} --target=${TARGET} --disable-nls
        * Build GCC [gcc-4.2.1]
            - ./configure --prefix=${PREFIX} --build=i686-pc-linux-gnu --target=${TARGET} --host=${TARGET}
                --disable-nls --enable-languages=c
        * Build bash [bash-4.0]
            - ./configure --prefix=${PREFIX} -host=${TARGET} --without-bash-malloc
            - install to $PREFIX/bin. And link $PREFIX/bin/sh to $PREFIX/bin/bash
        * Build gnu make [make-3.82]
            - ./configure --prefix=${PREFIX} -host={TARGET}
        * Build busybox
            - Set cross compiler prefix to 'arm-none-linux-gnueabi-' and make.
            - install to $PREFIX/bin
              (usually commands in busybox are located at /bin)
            - create link to busybox for each command.
        * copy to target device
            - adb push $PREFIX $TGNUROOT
        * link rootfs to gnu system root.
            - ln -s $TGNUROOT/lib /lib
            - ln -s $TGNUROOT/bin /bin
              ...

===============
Confirm & Check
===============
    Build Emacs-23.2
    ----------------
        * push Emacs-23.2 source code to target.
        * ./configure --without-xpm --without-jpeg --without-tiff --without-gif --without-png --without-rsvg
             --without-xft --without-libotf --without-m17n-flt --without-toolkit-scroll-bars --without-xaw3d
             --without-xim --without-gpm
        * 'make' should be done without error.

    Running Emacs
    -------------
        * copy termcap.src from "http://www.opensource.apple.com/source/emacs/emacs-39/emacs/etc/termcap.src".
          And put this /usr/etc/termcap.src.
        * And set following environment variable
            TERM=linux
            TERMCAP=/usr/etc/termcap.src
        * Emacs should work without error in 'adb shell' terminal.

===============
NOTE
===============
    Points
    ------
        * headers and GLIBC built for cross-compiling should be used as they are at target system root.
          (To use cross-compiled binaries on target device without any potential issues.)
        * Some open source packages check only /lib and /usr/lib (/usr/local/lib isn't considered).
          So, fundamental libraries would be better to be installed at /usr/lib,
         even if it's default location is /usr/local/lib

Setting up gnu system root is the first step to construct gnu software stack on the system.
And, now it’s done.
So, next step is installing packages to set up development-friendly environment on the Android device.
Below description is summary of issues that I faced against during installing gnu packages.

* Executing /usr/bin/su doesn't run ~/.bashrc
    ~/.bashrc is not executed if user shell is set up as /bin/sh, even if /bin/sh is just symbolic link of /bin/bash.
    Let's assume that /bin/sh -> /bin/bash.
    In this case, executing /bin/sh means "run bash as just 'shell' - sh".
    So, to make ~/.bashrc be run automatically, default shell of user should be set as /bin/bash not /bin/sh

* default .bashrc of normal(ex. ubuntu) desktop PC can be used as a template in Android device.

* terminal editor programs - vi, nano, emacs etc - don't work or work abnormally.
    Environment related with 'Terminal' should be set correctly.
        - Environment variables
            export TERM=xterm
            export TERMINFO=/etc/terminfo
            export TERMCAP=/etc/termcap
    Related files at /etc
        terminfo
            this has setting values for various terminal types - linux, vt100, xterm and so on.
            /etc/terminfo of desktop linux PC can be used as it is.
        termcap
            this is required by emacs.
            termcap.src(included at termcap source release) can be used as /etc/termcap.

* mode of newly created file becomes 0666 or 0777.
    umask should be set at .bashrc .
        umask 022

* window of editor programs like vi, emacs is default screen size (80x24)
 even if real screen size of terminal emulator is bigger.
    resize command should be executed.
    putting it at .bashrc is recommended.
    this command sets environment variables - COLUMNS and LINES - according to current terminal window size
   and export it.

* various colors are not used at the output of ls command.
    check that dircolors command is installed and this command is set correctly at .bashrc

* sudo command doesn't give any chance to enter password. It only says "Sorry, try again.".
    pam is not correctly binded with sudo.
    install /etc/pam.d/sudo file.
    (sample.pam included at sudo source code release can be a good reference.
     - especially, second option - use pam_unix - is recommended)

* icmp protocol is not recognized by ping - included at inetutils - command.
    check /etc/protocols file is correctly installed.
    this file can be used by copying desktop's one.

* localhost is not recognized even though ip address - 127.0.0.1  - works well.
    check followings at /etc/hosts
        127.0.0.1    localhost
    check below line at /etc/nsswitch.conf (related with nameserver)
        hosts: files dns

Anything to do?