Danilo's Tech Blog

This blog has moved!

2026-10-18T15:50:49.249-04:00

All my posts, plus new ones, now live at giulianelli.com/notebook. You’ll also find my Bell Labs-era career, patents and 3D-printing projects there. Thanks for reading! — Danilo

Simplified script to cross-compile Python-4-Android for both ARM NEON and x86

2015-06-01T22:23:00.000-04:00

I've created a simple script to cross-compile Python-4-Android for both the ARM NEON AND x86 architectures. This script only works with the patched Python-4-Android archive you can download from this post. I successfully ran the script on a Ubuntu 13.04 machine using the Android NDK version r9c.

First download both the make.sh script and python-for-android.tar.bz2 files in the same directory:

Cross-compiling Python-4-Android for ARM NEON

To cross-compile for ARM NEON, run make.sh with the following options:

$ make.sh -x -n /path/to/android-ndk-r9c -a armeabi-v7a-NEON -t arm-linux-androideabi-4.8

Cross-compiling Python-4-Android for x86

To cross-compile for x86, run make.sh with the following options:

$ make.sh -x -n /path/to/android-ndk-r9c -a x86 -t x86-4.6

ndk-gdb error: Could not extract package's data directory. Are you sure that your installed application is debuggable?

2014-02-27T11:44:00.000-05:00

The Problem

You have a phone running Android 4.3 and you are trying to debug your native C++ application using the Android NDK version r9c with ndk-gdb.
When you enter the ndk-gdb command you get the error:

$ ndk-gdb   
ERROR: Could not extract package's data directory. Are you sure that
       your installed application is debuggable?

You can find a description of this problem in Android Issue number 58373.
I encountered this problem with a Samsung Galaxy S4 running Android 4.3.

The Solution

The easiest solution for me was to root the device and change the permissions of the run-as command to run as root. You can achieve this by running the following commands using the ADB shell:

$ su -

# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 4750 /system/bin/run-as
# mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system

Once upon a time there were Bell Labs...

2013-10-10T10:17:00.001-04:00

Today is another step closer to the end of an era for the old AT&T Bell Labs (now called AT&T Labs). Our valued colleague David Korn (inventor of the famous Korn Shell - ksh) is leaving the labs, and he sent us the following farewell message in a form of (what else?) a Korn Shell script:

cd /tmp
if [[ $(print hello) != hello ]] 2> /dev/null
then echo 'You should use ksh'
 alias print=echo
fi
trap 'rm mvs2*' EXIT
trap 'print "$year: dgk raptured to dgk@xxxxxxxxx"' TERM
for x in 76 78 80 81 83 86 87 88 89 90 91 93 95 99 100 103 107 108 110 112 113
do case $((year=1900+x)) in
 1976) print "$year: Hello Bell Telephone Labs, Holmdel; Goodbye NYU";;
 1978) print "$year: create 'formshell' for RBCS from Bourne shell";;
 1980) print "$year: leave Bell Telephone Labs and return to NYU";;
 1981) print "$year: return to Bell Telephone Labs Murray Hill Bldg 5"
  print "$year: meet erg north dgb and kpv";;
 1983) print "$year: first version of ksh with editing and job control";
  print "$year: dgb becomes my supervisor"
  print "$year: UNIX for apollo with erg and ed fisher";;
 1986) print "$year: compete with kpv for best malloc library";;
 1987) print "$year: win best one liner in obfuscated C contest"
  print "$year: began long and continuing collaboration with gsf";;
 1988) print "$year: KornShell 88 book published";;
 1989) print "$year: 3d file system with gsf and ekrell";;
 1990) print "$year: sfio with kpv";;
 1991) print "$year: begin ast library with gsf";;
 1993) print "$year: first version of ksh93";;
 1995) print "$year: 1993 KornShell book published"
  print "$year: first version of UWIN"
  print "$year: Bell Labs split to AT&T Labs and Lucent";;
 1997) print "$year: move to Florham Park";;
 1999) print "$year: y2k testing software created";;
 2000)  print "$year: ast software becomes self documenting";;
 2003) > mvs2pc; print "$year: create mvs2pc";;
 2007) print "$year: Universal Biller invoicing runs with msv2pc";;
 2008) print "$year: UWIN merged into VizGems written in ksh by Dr. ek"
  print "$year: merged mfcobol compiler into mvs2pc";;
 2010) print "$year: distributed shell using coshell";;
 2012) mv mvs2pc mvs2cloud; print "$year: rename mvs2pc to mvs2cloud";;
 2013) kill -TERM $$;;
 esac
done
exit

How to debug Android Native Code with Eclipse

2013-08-22T09:29:00.001-04:00

This blog summarizes the steps needed to set-up your Eclipse environment to support the debugging of an Android native application written in C/C++. It's taken from an old Carlos Suoto's web page that doesn't seem to exist anymore.

1. Pre-Requisites

Make sure you compile your C/C++ with the "-g" option (or use -DCMAKE_BUILD_TYPE:STRING="Debug" if you use cmake).
Make sure APP_OPTIM is set to "APP_OPTIM:=debug" in Android.mk and Application.mk.
Make sure build/core/build-binary.mk in Android NDK doesn't strip executables. For example patch android-ndk-r8e/build/core/build-binary.mk to the following:

--- build/core/build-binary.mk.orig     2013-08-21 11:06:39.818329442 -0400
+++ build/core/build-binary.mk 2013-08-21 11:13:11.877214361 -0400
@@ -485,10 +485,16 @@ $(LOCAL_INSTALLED): PRIVATE_DST       :=
$(LOCAL_INSTALLED): PRIVATE_STRIP     := $(TARGET_STRIP)
$(LOCAL_INSTALLED): PRIVATE_STRIP_CMD := $(call cmd-strip, $(PRIVATE_DST))

+ifeq ($(APP_OPTIM),debug)
+$(LOCAL_INSTALLED): $(LOCAL_BUILT_MODULE) clean-installed-binaries
+       @$(HOST_ECHO) "Install        : $(PRIVATE_NAME) => $(call pretty-dir,$(PRIVATE_DST))"
+       $(hide) $(call host-install,$(PRIVATE_SRC),$(PRIVATE_DST))
+else
$(LOCAL_INSTALLED): $(LOCAL_BUILT_MODULE) clean-installed-binaries
        @$(HOST_ECHO) "Install        : $(PRIVATE_NAME) => $(call pretty-dir,$(PRIVATE_DST))"
        $(hide) $(call host-install,$(PRIVATE_SRC),$(PRIVATE_DST))
        $(hide) $(PRIVATE_STRIP_CMD)
+endif

1.1. Install the Eclipse Sequoyah plugin

In Eclipse go to Help -> Install New Software
Click on the Add button
Enter 'Sequoyah Metadata Repository' in the Name field
Enter 'http://download.eclipse.org/sequoyah/updates/2.0/' in the Location field
If you still see the "There are no categorized items" message, uncheck the "Group items by category" radio button
Select "Sequoyah Android Native Code Support" and install the plugin

1.2. Convert The Android Java Application into C/C++ Project

You must convert your Java project to C/C++ using the Sequoyah plugin or else you won't be able to see the configuration options to set the proper debugger settings.

In Eclipse select the Android Java project you need to convert
Right click with the mouse and select Android Tools -> Add Native Support

1.3. Other Pre-Requisites

The platform must be Android 2.2 (android-8) or later
The ndk version must be r4b (it contains bugfixes to ndk-gdb that are necessary) or later
Eclipse CDT 7.0 or newer must be installed
The AndroidManifest.xml must have the property of the application node android:debuggable="true"
The build must have been done with the ndk-build (if using the Sequoyah Android components, it will be automatic)

2. Configurations

01) Create a debug configuration for an Android application (can be done with Eclipse or MOTODEV Studio)
02) Create a debug configuration for a C/C++ application

03) Set the following properties:

04) The process launcher must be the Standard Process Launcher. This is selected at the bottom of the Main tab:

05) On the "Main" tab:
the Field C/C++ Application: $PROJECT_PATH/obj/local/armeabi/app_process
06) On the "Debugger" tab:
- field Debugger: gdbserver
- On the "Main" subtab:
- 07) GDB debugger: $NDK_PATH/build/prebuilt/$ARCH/arm-eabi-$GCC_VERSION/bin/arm-eabi-gdb
- 08) GDB command file: $PROJECT_PATH/obj/local/armeabi/gdb2.setup
  [Windows users] Uncheck the "Use full file path to set breakpoints" option
- On the "Connection" subtab:
- 09) Type: TCP
- 10) Hostname or IP address: localhost
- 11) Port number: 5039
3. Instructions
Open the ndk-gdb script that came with the android NDK and comment the last line (we are not calling the usual gdb client, but we will attach an Eclipse gdb session instead):
- ```
    # $GDBCLIENT -x $GDBSETUP -e $APP_PROCESS
```
Insert a breakpoint in your Java code, preferably after all System.loadLibrary() calls. (To make sure that the debugger is correctly attached to the Java process)
Launch the android debug and wait for it to reach the breakpoint
From a Terminal session, in the project folder, run the modified ndk-gdb command. It should not attach to an gdb client, but call the gdbserver on the emulator and open a TCP port for connection (or in alternative if you have an Android device connected to your USB port, the ndk-gdb script will run gdbserver on the device itself).
In the $PROJECT_PATH/obj/local/armeabi/, modify the gdb.setup file, removing the target remote:5039 statement. (For some reason, the Eclipse GDB session does not like this statement being done in the commands file). Rename this new file to gdb2.setup. This step need to be run just once, on the first debug session.
Launch the C/C++ Application debug and wait for the Eclipse GDB session to fully connect to the emulator's gdbserver instance.

After following these steps, one can continue to debug the application as usual, using the "continue" option to let the execution flow until the next breakpoint is hit or by using the usual "step-in" to execute each statement individually. Setting a breakpoint on a Java statement that calls a native function through JNI and stepping into will place the user at the beginning of the native code.
Another way to set breakpoints in the C/C++ code is from Eclipse to click on File -> Open File and browse to the location of your source code. Then double-click on the line where you want to set the breakpoint.

How to compile libogg for Android

2013-05-09T15:04:00.001-04:00

To compile libogg for Android, you just need to create an appropriate jni/Android.mk makefile with the minimum set of files and options needed to compile libogg for Android.

Download ogg from http://downloads.xiph.org/releases/ogg/ (for example I downloaded libogg-1.1.4.tar.gz)
untar the file in your local directory:

$ tar zxf libogg-1.1.4.tar.gz
create a jni directory and put the following text into a file named jni/Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE    := ogg
LOCAL_CFLAGS    := \
    -DFIXED_POINT -DUSE_KISS_FFT -DEXPORT="" -UHAVE_CONFIG_H \
    -D_ANDROID
LOCAL_C_INCLUDES := \
    ../libogg-1.1.4/include
LOCAL_SRC_FILES := \
    ../libogg-1.1.4/src/bitwise.c \
    ../libogg-1.1.4/src/framing.c
include $(BUILD_SHARED_LIBRARY)
Now your directory should look like the following:

$ ls
jni/ libogg-1.1.4/ libogg-1.1.4.tar.gz
change directory to jni and run ndk-build:

$ cd jni; ndk-build V=1

That should do it.

How to compile busybox with Android NDK for both ARM and x86 architectures

2013-02-20T22:56:00.001-05:00

I was looking for a way to run busybox on a Motorola RAZRi with an x86 Intel Atom processor but I couldn't find any Android app from the Google play market that was running on the phone (when running any busybox command nothing happened and I was immediately getting the prompt back).
So I decided to cross-compile busybox for Android myself. Now you will find other posts claiming to have done so by downloading an ARM-cross compiler from codesourcery.com but I had two problems with that approach:

I needed an x86 cross-compiler and,
I read various complaints of people not being able to run various busybox commands with this method.

Cross-compiling busybox with the Android NDK

My only option was to use the Android NDK itself, since it comes with full support of the ARM, x86, and MIPS architectures. I ended up manually configuring busybox by eliminating any module that would not cross-compile due to missing header files and/or libraries in the Android NDK.
To cut the story short, I managed to cross-compile busybox using the Android NDK compilers for both ARM and x86 architectures (I didn't try MIPS since I don't have a device with a MIPS processor to test the resulting binaries).
To build busybox yourself, download the busybox-android.patch, busybox-android.config, and build.sh script and run the latter with the following options:

$ build.sh <android NDK dir> <NDK toolchain> <Android ABI> <Toolchain compiler version> <Android Native API Level> <Install prefix>

The script will download the busybox version 1.21.0 source code, apply the busybox-android.patch and configure busybox for the right architecture.
For example if you have your Android NDK installed under /home/android/android-ndk-r8d, to build busybox for the Intel x86 architecture call the build.sh script like the following:

$ build.sh /home/android/android-ndk-r8d x86-4.7 x86 4.7 android-14 /home/android/busybox-x86

and the cross-compiled busybox binaries will be installed under the /home/android/busybox-x86 directory. Similarly if you want to build busybox for the ARM processor, run the following:

$ build.sh /home/android/android-ndk-r8d arm-linux-androideabi-4.7 armeabi-v7a 4.7 android-14 /home/android/busybox-arm

Download busybox binaries

The busybox binaries for x86 (compiled using the above procedure), can be found here.

Installing busybox

The above procedure was tested with release r8d of the Android NDK and for both ARM and x86 devices.

Pre-requisites

Your phone must be rooted (for example check out my blog How to root Motorola RAZRi XT890 running Android 4.0.4)
You must activate USB debugging mode on your device by going to Settings -> Developer Options -> USB Debugging and selecting the corresponding check box.

Installation Procedure

To install busybox on an x86 Android (rooted) device, I run the following commands with the phone connected to the computer via USB:

# logon to the phone and become root to mount the /system file system read/write
$ adb shell
shell@android:/ $ su -
shell@android:/ # mount -o rw,remount -t ext4 /dev/block/system /system
shell@android:/ # chmod 0777 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$

then change directory to the location of the busybox binary file and push it to the phone:

$ adb push busybox /system/xbin/

log back on as root and change permissions appropriately:

$ adb shell
shell@android:/ $ su -
shell@android:/ # chmod 755 /system/xbin/busybox
shell@android:/ # chmod 0755 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$

Installing busybox on an ARM Android device is very similar, only the mounting instruction line changes:

$ adb shell
shell@android:/ $ su -
shell@android:/ # mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
shell@android:/ # chmod 0777 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$
$ adb push busybox /system/xbin/
$ adb shell
shell@android:/ $ su -
shell@android:/ # chmod 755 /system/xbin/busybox
shell@android:/ # chmod 0755 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$

How to build the gcc Fortran cross-compiler for Android (ARM and x86)

2013-02-12T10:09:00.000-05:00

If you need to cross-compile for Android a program written in Fortran, you know already that the official Android NDK does not come with the gfortran compiler, and if like me you need to port to Android code that depends on Fortran (such as the lapack libraries), you are out of luck.
Fortunately I managed to compile the gcc Fortran cross-compiler with the help of Mike Long's blog. As an added bonus, I managed to build gfortran 4.8.0 not only for the ARM but also for the x86 toolchain, as well as update the script to the latest Android NDK (currently r8d).
What you need to do is the following:

download the fortran4android shell script.
download the ndk-r8d fortran patch.
run the script in your directory:

$ fortran4android
wait, wait, wait, ... and you will see in the android-ndk-r8d/toolchains directory two new toolchains called arm-linux-androideabi-4.8.0 and x86-4.8.0
Enjoy your new gfortran compiler.

Note that I've successfully tested the script only on Ubuntu 12.04.

Addendum of August 30, 2013

I now have available a patch for the newer android-ndk-r9. To use this instead of the patch above:

download the ndk-r9-fortran-patch
change the fortran4android script by replacing "r8d" with "r9" everywhere
run the fortran4android script in your directory.

Note that r9 of the NDK already comes with a 4.8 gcc toolchain and to keep it separated, the fortran4android script will still generate in output a "4.8.0" toolchain.

How to root Motorola RAZRi XT890 running Android 4.0.4

2013-02-11T15:47:00.000-05:00

This procedure is only valid for Motorola RAZRi model XT890 (Intel inside) running Android 4.0.4 (system version 81.5.39001.XT890.Retail.en.GB). The following instructions refer to rooting the RAZRi from a Windows 7 PC.

You need to download the Android SDK

Go to the Android Developer web site and download the Android SDK for Windows.

Make sure you then set the PATH environment variable to the <sdk>\platform-tools directory where all the tools can be found from the command line.

Install the latest Motorola USB drivers for you phone

Install the latest Motorola USB Drivers. Get them here.

Your phone should be factory unlocked

This is a must or else rooting the device will fail with the phone stuck on the bootloader. Go to the Motorola Web site and follow the step by step instructions. Basically open a Command Prompt window and get your Device ID by running the fastboot command. The instructions from Motorola are the following:

Put your device in fastboot mode (press the power button and volume down button at the same time and connect your device to your computer with a USB cable).
On your computer, open a command prompt or Terminal session.
Go to the Directory where you installed the Android SDK tools, and type:$ fastboot oem get_unlock_data
This fastboot command will return a character string. This is the Device ID which you will be using to generate your unique unlock key.

Example Device ID (PC User)$ fastboot oem get_unlock_data
(bootloader) 0A40040192024205#4C4D3556313230
(bootloader) 30373731363031303332323239#BD00
(bootloader) 8A672BA4746C2CE02328A2AC0C39F95
(bootloader) 1A3E5#1F53280002000000000000000
(bootloader) 0000000

At this point if you submit the device ID to the web form, Motorola will send you the unlock code via e-mail (after warning you that the warranty will be void if you do so).
To unlock the device:

Turn off your device.
Start your device in fastboot mode. To do this on most Motorola devices, push and hold the power and volume down at the same time, release the power button then release volume down. The device will power up in fastboot mode
Connect the device to the computer with a USB cable. You'll get a confirmation message on the device will indicate that it's connected.
Open a command window or terminal on your computer.
Change field to show the path to the tools folder within the Android SDK folder.
Verify that the desktop and device are connected by entering the following in the command field:$ fastboot devicesYou should see that your device is connected.
Now you will unlock the bootloader. Simply enter the following in the command line:$ fastboot oem unlock UNIQUE_KEYThe UNIQUE_KEY is the code you received in the email. It is case-sensitive.
If the line was entered correctly, your device's screen will confirm that your device is unlocked. You have just unlocked your device's bootloader.

Root the device

Get the RAZRi rooting utility for Windows. Get it here.
Extract the zipped files and from a Command Prompt or terminal window, change directory to the location of the utility. Make sure your RAZRi is connected to your Windows PC via the USB cable. Finally run the Root.bat command, follow the instructions, and cross your fingers.
After rebooting at least three times the phone should be rooted.

How to build Python-4-Android for the ARM Neon

2013-01-31T18:09:00.003-05:00

Currently the Py4A project does not compile for the ARM Neon architecture. If you try to run ndk-build on the project by setting the APP_ABI to armeabi-v7a and setting the LOCAL_ARM_NEON variable to true, you get the following error:

libffi/src/arm/sysv.S: Assembler messages:
libffi/src/arm/sysv.S:203: Error: selected processor does not support ARM mode `stfeqs f0,[r2]'
libffi/src/arm/sysv.S:208: Error: selected processor does not support ARM mode `stfeqd f0,[r2]'
libffi/src/arm/sysv.S:283: Error: selected processor does not support ARM mode `ldfs f0,[sp]'
libffi/src/arm/sysv.S:286: Error: selected processor does not support ARM mode `ldfd f0,[sp]'
libffi/src/arm/sysv.S:289: Error: selected processor does not support ARM mode `ldfd f0,[sp]'
make: *** [obj/local/armeabi-v7a/objs/ffi/src/arm/sysv.o] Error 1

The following patch for the python-build/libffi/src/asm/sysv.S file allows you to cross-compile Py4A for the armeabi-v7a ABI and also for the Neon instruction set. The patch consists in appropriately changing the conditionals containing __SOFTFP__ and adding __SOFTFP__ || __ARM_EABI__.
For example to build for the ARM Neon instruction set, the ndk-build command line in build.sh should be the following:

ndk-build APP_ABI:=armeabi-v7a LOCAL_ARM_NEON:=true

--- libffi/src/arm/a/sysv.S    2013-01-30 14:49:29.711595414 -0500
+++ libffi/src/arm/sysv.S    2013-01-31 18:05:07.376178842 -0500
@@ -189,7 +189,7 @@ ARM_FUNC_START ffi_call_SYSV

@ return INT
     cmp    r3, #FFI_TYPE_INT
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
     cmpne    r3, #FFI_TYPE_FLOAT
#endif
     streq    r0, [r2]
@@ -197,12 +197,12 @@ ARM_FUNC_START ffi_call_SYSV

     @ return INT64
     cmp    r3, #FFI_TYPE_SINT64
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
     cmpne    r3, #FFI_TYPE_DOUBLE
#endif
     stmeqia    r2, {r0, r1}

-#ifndef __SOFTFP__
+#if !defined(__SOFTFP__) && !defined(__ARM_EABI__)
     beq    LSYM(Lepilogue)

@ return FLOAT
@@ -245,21 +245,21 @@ ARM_FUNC_START ffi_closure_SYSV
     beq    .Lretint

     cmp    r0, #FFI_TYPE_FLOAT
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
     beq    .Lretint
#else
     beq    .Lretfloat
#endif

     cmp    r0, #FFI_TYPE_DOUBLE
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
     beq    .Lretlonglong
#else
     beq    .Lretdouble
#endif

     cmp    r0, #FFI_TYPE_LONGDOUBLE
-#ifdef __SOFTFP__
+#if defined(__SOFTFP__) || defined(__ARM_EABI__)
     beq    .Lretlonglong
#else
     beq    .Lretlongdouble
@@ -278,7 +278,7 @@ ARM_FUNC_START ffi_closure_SYSV
     ldr    r1, [sp, #4]
     b    .Lclosure_epilogue

-#ifndef __SOFTFP__
+#if !defined(__SOFTFP__) && !defined(__ARM_EABI__)
.Lretfloat:
     ldfs    f0, [sp]
     b    .Lclosure_epilogue

How to build Python-4-Android for the x86

2013-01-29T15:57:00.001-05:00

Currently the Py4A project only compiles for the ARM architecture.

The following patch for the python-build sub-directory allows you to cross-compile Py4A for the x86 architecture. The patch consists in:

Adding a set of new files to support the x86 architecture (including creating a new libffi/linux-x86/ directory):

libffi/linux-x86/ffi.h
libffi/linux-x86/fficonfig.h
setup-x86.cfg
changing the build.sh script to accept a new parameter - the Android ABI (for example 'armeabi' or 'x86') - so that the script can call

ndk-build APP_ABI:=x86

to trigger the cross-compilation for the x86 processor;
changing the build.py script to parametrize the GCC strip command and the selection of the setup.cfg configuration file based on the input ABI;
changing the libffi/Android.mk makefile to select the right set of source files based on the input ABI;
changing the libffi/include/ffi_real.h header file to redefine FFI_TYPE_LONGDOUBLE to 4;
changing the openssl/crypto/Android.mk and openssl/ssl/Android.mk makefiles to strip down the openssl library with only the bare minimum set that allows you to cross-compile the source code;
changing the python/jni/modules.mk makefile to add the -fno-stack-protector compiler and linker option when building the _socket module and exclude the openssl module.

After applying the patch, to cross-compile Py4A for the x86 architecture you should run the following:

$ cd python-build

$ ./build.sh x86

Binaries for the x86 can be downloaded here:

--- orig/python/jni/modules.mk    2013-01-21 14:39:56.000000000 -0500
+++ python/jni/modules.mk    2013-01-29 14:58:52.922096000 -0500
@@ -58,7 +58,7 @@ $(call build-module, syslog , Modules/
$(call build-module, audioop , Modules/audioop.c )
$(call build-module, imageop , Modules/imageop.c )
$(call build-module, _csv , Modules/_csv.c )
-$(call build-module, _socket , Modules/socketmodule.c, libc, -lc, -nostdlib )
+$(call build-module, _socket , Modules/socketmodule.c, libc, -lc -fno-stack-protector, -nostdlib -fno-stack-protector )
$(call build-module, _sha , Modules/shamodule.c )
$(call build-module, _md5 , Modules/md5module.c Modules/md5.c )
$(call build-module, _sha256 , Modules/sha256module.c )
@@ -125,6 +125,7 @@ include $(BUILD_SHARED_LIBRARY)

#$(call build-module, _ssl , Modules/_ssl.c, ssl crypto )

+ifneq ($(APP_ABI), x86)
$(call import-module, openssl)
LOCAL_PATH := $(PYTHON_SRC_PATH)
LOCAL_C_INCLUDES += $(PYTHON_SRC_PATH) $(PYTHON_SRC_PATH)/Include $(OPENSSL)/include $(OPENSSL)
@@ -133,6 +134,7 @@ LOCAL_MODULE_FILENAME := _ssl
LOCAL_SRC_FILES := Modules/_ssl.c
LOCAL_SHARED_LIBRARIES := libpython2.6 libcrypto libssl
include $(BUILD_SHARED_LIBRARY)
+endif

$(call import-module, libffi)
--- orig/setup-x86.cfg    1969-12-31 19:00:00.000000000 -0500
+++ setup-x86.cfg    2013-01-28 16:09:49.004463929 -0500
@@ -0,0 +1,2 @@
+[bdist_egg]
+plat-name=linux-x86
--- orig/openssl/ssl/Android.mk    2013-01-21 14:42:17.000000000 -0500
+++ openssl/ssl/Android.mk    2013-01-28 16:33:35.563643087 -0500
@@ -7,6 +7,10 @@ local_c_includes := \

include $(CLEAR_VARS)

+ifeq ($(APP_ABI), x86)
+LOCAL_SRC_FILES:= \
+    kssl.c
+else
LOCAL_SRC_FILES:= \
     s2_meth.c \
     s2_srvr.c \
@@ -45,6 +49,7 @@ LOCAL_SRC_FILES:= \
     bio_ssl.c \
     ssl_err.c \
     kssl.c
+endif

include $(LOCAL_PATH)/../android-config.mk

--- orig/openssl/crypto/Android.mk    2013-01-21 14:42:08.000000000 -0500
+++ openssl/crypto/Android.mk    2013-01-29 14:49:00.334324159 -0500
@@ -2,27 +2,17 @@ LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_CFLAGS += -DOPENSSL_BN_ASM_MONT -DAES_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DOPENSSL_NO_STATIC_ENGINE
+ifneq ($(APP_ABI), x86)
LOCAL_SRC_FILES:= 0.9.9-dev/bn/armv4-mont.s \
                   0.9.9-dev/aes/aes-armv4.s \
                   0.9.9-dev/sha/sha1-armv4-large.s \
                   0.9.9-dev/sha/sha256-armv4.s \
                   0.9.9-dev/sha/sha512-armv4.s
-
LOCAL_SRC_FILES+= \
-    cryptlib.c \
-    mem.c \
-    mem_clr.c \
     mem_dbg.c \
-    cversion.c \
     dyn_lck.c \
     ex_data.c \
-    tmdiff.c \
     cpt_err.c \
-    ebcdic.c \
-    uid.c \
-    o_time.c \
-    o_str.c \
-    o_dir.c \
     aes/aes_misc.c \
     aes/aes_ecb.c \
     aes/aes_cbc.c \
@@ -474,6 +464,19 @@ LOCAL_SRC_FILES+= \
     ripemd/rmd_dgst.c \
     ripemd/rmd_one.c \
     evp/m_ripemd.c
+endif
+
+LOCAL_SRC_FILES+= \
+    cryptlib.c \
+    mem.c \
+    mem_clr.c \
+    cversion.c \
+    tmdiff.c \
+    ebcdic.c \
+    uid.c \
+    o_time.c \
+    o_str.c \
+    o_dir.c

LOCAL_CFLAGS += -DNO_WINDOWS_BRAINDEATH

--- orig/build.py    2013-01-21 14:44:17.000000000 -0500
+++ build.py    2013-01-28 16:19:35.088015089 -0500
@@ -82,6 +82,10 @@ def rm(path):

def strip(path):
+ if len(sys.argv) > 1:
+    if sys.argv[1] == "x86":
+      run('i686-linux-android-strip %s' % path)
+    else:
   run('arm-linux-androideabi-strip %s' % path)

@@ -153,6 +157,12 @@ map(rm, find('output.temp/usr/lib/python
map(rm, find('output.temp', 'python$', exclude=['setuptools', 'distutils'])[0])
run("mkdir python", cwd="output.temp/usr")
run("cp -r %s/python-libs/py4a python" % pwd, cwd="output.temp/usr")
+if len(sys.argv) > 1:
+    if sys.argv[1] == "x86":
+        run("cp %s/setup-x86.cfg ." % pwd, cwd="output.temp/usr")
+    else:
+        run("cp %s/setup.cfg ." % pwd, cwd="output.temp/usr")
+else:
run("cp %s/setup.cfg ." % pwd, cwd="output.temp/usr")
run("cp %s/prepare_setuptools.sh setup.sh" % pwd, cwd="output.temp/usr")
run("cp %s/standalone_python.sh python.sh" % pwd, cwd="output.temp/usr")
--- orig/libffi/include/ffi_real.h    2013-01-21 14:42:35.000000000 -0500
+++ libffi/include/ffi_real.h    2013-01-29 10:27:30.664550823 -0500
@@ -371,8 +371,12 @@ void ffi_call(ffi_cif *cif,
#if CONF_HAVE_LONG_DOUBLE       // android changed
#define FFI_TYPE_LONGDOUBLE 4
#else
+#ifdef x86
+#define FFI_TYPE_LONGDOUBLE 4
+#else
#define FFI_TYPE_LONGDOUBLE FFI_TYPE_DOUBLE
#endif
+#endif
#define FFI_TYPE_UINT8      5
#define FFI_TYPE_SINT8      6
#define FFI_TYPE_UINT16     7
--- orig/libffi/Android.mk    2013-01-21 14:42:42.000000000 -0500
+++ libffi/Android.mk    2013-01-28 17:00:21.190897854 -0500
@@ -21,6 +21,17 @@ include $(CLEAR_VARS)

LOCAL_MODULE := ffi
LOCAL_MODULE_FILENAME :=
+ifeq ($(APP_ABI), x86)
+    LOCAL_SRC_FILES := src/x86/sysv.S \
+    src/x86/ffi.c \
+    src/debug.c \
+    src/java_raw_api.c \
+    src/prep_cif.c \
+    src/raw_api.c \
+    src/types.c
+
+    LOCAL_C_INCLUDES := $(LOCAL_PATH)/include $(LOCAL_PATH)/linux-x86
+else
LOCAL_SRC_FILES := src/arm/sysv.S \
     src/arm/ffi.c \
     src/debug.c \
@@ -30,6 +41,7 @@ LOCAL_SRC_FILES := src/arm/sysv.S \
     src/types.c

LOCAL_C_INCLUDES := $(LOCAL_PATH)/include $(LOCAL_PATH)/linux-arm
+endif
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)

$(call __ndk_info, Building libffi)
--- orig/libffi/linux-x86/ffi.h    1969-12-31 19:00:00.000000000 -0500
+++ libffi/linux-x86/ffi.h    2013-01-28 16:24:28.975890002 -0500
@@ -0,0 +1,10 @@
+/*
+ * Copyright 2008 The Android Open Source Project
+ */
+#ifndef LIBFFI_H
+
+#define x86
+#include "../src/x86/ffitarget.h"
+#include "../include/ffi_real.h"
+
+#endif
--- orig/libffi/linux-x86/fficonfig.h    1969-12-31 19:00:00.000000000 -0500
+++ libffi/linux-x86/fficonfig.h    2013-01-28 16:23:04.047926730 -0500
@@ -0,0 +1,160 @@
+/* fficonfig.h.in. Generated from configure.ac by autoheader. */
+
+/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
+   systems. This function is required for `alloca.c' support on those systems.
+   */
+#undef CRAY_STACKSEG_END
+
+/* Define to 1 if using `alloca.c'. */
+#undef C_ALLOCA
+
+/* Define to the flags needed for the .section .eh_frame directive. */
+#define EH_FRAME_FLAGS "aw"
+
+/* Define this if you want extra debugging. */
+#undef FFI_DEBUG
+
+/* Define this is you do not want support for the raw API. */
+#undef FFI_NO_RAW_API
+
+/* Define this is you do not want support for aggregate types. */
+#undef FFI_NO_STRUCTS
+
+/* Define to 1 if you have `alloca', as a function or macro. */
+#define HAVE_ALLOCA 1
+
+/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix).
+   */
+#define HAVE_ALLOCA_H 1
+
+/* Define if your assembler supports .cfi_* directives. */
+#undef HAVE_AS_CFI_PSEUDO_OP
+
+/* Define if your assembler supports .register. */
+#undef HAVE_AS_REGISTER_PSEUDO_OP
+
+/* Define if your assembler and linker support unaligned PC relative relocs.
+   */
+#undef HAVE_AS_SPARC_UA_PCREL
+
+/* Define to 1 if you have the <dlfcn.h> header file. */
+#define HAVE_DLFCN_H 1
+
+/* Define if __attribute__((visibility("hidden"))) is supported. */
+#undef HAVE_HIDDEN_VISIBILITY_ATTRIBUTE
+
+/* Define to 1 if you have the <inttypes.h> header file. */
+#define HAVE_INTTYPES_H 1
+
+/* Define if you have the long double type and it is bigger than a double */
+#undef HAVE_LONG_DOUBLE
+
+/* Define to 1 if you have the `memcpy' function. */
+#define HAVE_MEMCPY 1
+
+/* Define to 1 if you have the <memory.h> header file. */
+#define HAVE_MEMORY_H 1
+
+/* Define to 1 if you have the `mmap' function. */
+#define HAVE_MMAP 1
+
+/* Define if mmap with MAP_ANON(YMOUS) works. */
+#define HAVE_MMAP_ANON 1
+
+/* Define if mmap of /dev/zero works. */
+#define HAVE_MMAP_DEV_ZERO 1
+
+/* Define if read-only mmap of a plain file works. */
+#define HAVE_MMAP_FILE 1
+
+/* Define if .eh_frame sections should be read-only. */
+#undef HAVE_RO_EH_FRAME
+
+/* Define to 1 if you have the <stdint.h> header file. */
+#define HAVE_STDINT_H 1
+
+/* Define to 1 if you have the <stdlib.h> header file. */
+#define HAVE_STDLIB_H 1
+
+/* Define to 1 if you have the <strings.h> header file. */
+#undef HAVE_STRINGS_H
+
+/* Define to 1 if you have the <string.h> header file. */
+#define HAVE_STRING_H 1
+
+/* Define to 1 if you have the <sys/mman.h> header file. */
+#define HAVE_SYS_MMAN_H 1
+
+/* Define to 1 if you have the <sys/stat.h> header file. */
+#define HAVE_SYS_STAT_H 1
+
+/* Define to 1 if you have the <sys/types.h> header file. */
+#define HAVE_SYS_TYPES_H 1
+
+/* Define to 1 if you have the <unistd.h> header file. */
+#define HAVE_UNISTD_H 1
+
+/* Define to 1 if your C compiler doesn't accept -c and -o together. */
+#undef NO_MINUS_C_MINUS_O
+
+/* Name of package */
+#define PACKAGE "libffi"
+
+/* Define to the address where bug reports for this package should be sent. */
+#undef PACKAGE_BUGREPORT
+
+/* Define to the full name of this package. */
+#undef PACKAGE_NAME
+
+/* Define to the full name and version of this package. */
+#undef PACKAGE_STRING
+
+/* Define to the one symbol short name of this package. */
+#undef PACKAGE_TARNAME
+
+/* Define to the version of this package. */
+#undef PACKAGE_VERSION
+
+/* The size of `double', as computed by sizeof. */
+#define SIZEOF_DOUBLE 8
+
+/* The size of `long double', as computed by sizeof. */
+#undef SIZEOF_LONG_DOUBLE
+
+/* If using the C implementation of alloca, define if you know the
+   direction of stack growth for your system; otherwise it will be
+   automatically deduced at runtime.
+    STACK_DIRECTION > 0 => grows toward higher addresses
+    STACK_DIRECTION < 0 => grows toward lower addresses
+    STACK_DIRECTION = 0 => direction of growth unknown */
+#undef STACK_DIRECTION
+
+/* Define to 1 if you have the ANSI C header files. */
+#define STDC_HEADERS 1
+
+/* Define this if you are using Purify and want to suppress spurious messages.
+   */
+#undef USING_PURIFY
+
+/* Version number of package */
+#undef VERSION
+
+/* Define to 1 if your processor stores words with the most significant byte
+   first (like Motorola and SPARC, unlike Intel and VAX). */
+#undef WORDS_BIGENDIAN
+
+
+#ifdef HAVE_HIDDEN_VISIBILITY_ATTRIBUTE
+#ifdef LIBFFI_ASM
+#define FFI_HIDDEN(name) .hidden name
+#else
+#define FFI_HIDDEN __attribute__ ((visibility ("hidden")))
+#endif
+#else
+#ifdef LIBFFI_ASM
+#define FFI_HIDDEN(name)
+#else
+#define FFI_HIDDEN
+#endif
+#endif
+

--- build.sh (orig/build.sh)
+++ build.sh (build.sh)
@@ -5,6 +5,7 @@
set -ex
CWD=$(pwd)
DEBUG=no
+android_abi="$1"

RELEASE_VERSION=$(cat LATEST_VERSION)
echo "Building Python VM For Android Release ${RELEASE_VERSION}"
@@ -78,12 +79,12 @@
${CWD}/host/pgen ${CWD}/python-src/Grammar/Grammar \
${CWD}/python-src/Include/graminit.h \
${CWD}/python-src/Python/graminit.c
-ndk-build
+ndk-build APP_ABI:=$android_abi

# copy out all the needed files
-mv obj/local/armeabi/python ${OUT}/usr/bin
-mv obj/local/armeabi/lib*.so ${OUT}/usr/lib
-mv obj/local/armeabi/*.so ${OUT}/usr/lib/python2.6/lib-dynload
+mv obj/local/$android_abi/python ${OUT}/usr/bin
+mv obj/local/$android_abi/lib*.so ${OUT}/usr/lib
+mv obj/local/$android_abi/*.so ${OUT}/usr/lib/python2.6/lib-dynload
popd

pushd ${CWD}/python-libs
@@ -91,7 +92,7 @@
popd

${CWD}/host/bin/python ${OUT}/usr/lib/python2.6/compileall.py ${OUT}/usr/lib/python2.6
-${CWD}/host/bin/python build.py
+${CWD}/host/bin/python build.py $android_abi

if [ "$DEBUG" != "yes" ]; then
rm -rf output*

Android: Trying to load native library results in a process terminated by signal (11)

2013-01-24T10:25:00.000-05:00

Symptoms

You are trying to load your native C/C++ library in an Android application and when at runtime your app calls the System.loadLibrary() function - for example:

static {

        System.loadLibrary("mynativelib");

}

the application dies without core dumping, and the only message you see in LogCat is something like the following:

01-23 19:58:08.699: D/dalvikvm(4146): Trying to load lib /data/data/com.example.myapp/lib/libmynativelib.so 0x42341a50

01-23 19:58:08.709: I/ActivityManager(340): Process com.example.myapp (pid 4146) has died.

01-23 19:58:08.709: W/ActivityManager(340): Force removing ActivityRecord{211d37d0 com.example.myapp/.MyActivity}: app died, no saved state

01-23 19:58:08.719: D/Zygote(188): Process 4146 terminated by signal (11)

Causes

You native library is probably trying to dynamically load another library it depends upon.

Solution

Use the GCC readelf for your ABI to dump the dynamic section of your native library and find out which libraries it depends upon. For example if you are compiling for the x86 ABI:

$ android-ndk-r8d/toolchains/x86-4.7/prebuilt/linux-x86/bin/i686-linux-android-readelf -d libmynativelib.so | grep NEEDED
0x00000001 (NEEDED)                     Shared library: [libgnustl_shared.so]
0x00000001 (NEEDED)                     Shared library: [libiconv.so]
0x00000001 (NEEDED)                     Shared library: [libdl.so]
0x00000001 (NEEDED)                     Shared library: [libstdc++.so]
0x00000001 (NEEDED)                     Shared library: [libm.so]
0x00000001 (NEEDED)                     Shared library: [libc.so]

In this example you only need to load libgnustl_shared.so and libiconv.so before your libmynativelib.so to resolve the dependencies and make the System.loadLibrary() function call happy (the other standard libraries are already preloaded for you by Android). In your static section you will then include the following lines:

static {

        System.loadLibrary("gnustl_shared");

        System.loadLibrary("iconv");

        System.loadLibrary("mynativelib");

}

This should solve the problem.

How to port Mozilla SpiderMonkey 1.7 to Android

2013-01-10T10:47:00.001-05:00

Another third-party package I needed to cross-compile for Android was Mozilla's SpiderMonkey 1.7 Javascript engine. I found two issues here:

When configuring SpiderMonkey the makefile tries to build two executables (jscpucfg and jskwgen) and then runs them to generate two configuration header files (jsautocfg.h and jsautokw.h, respectively). The problem when using the Android NDK cross-compiler is that these two executables can only be run on the Android target (for example an ARM processor), while I'm cross-compiling my build from a Linux Ubuntu 12.04 machine with an x86_64 processor architecture. So you get an error that you cannot execute these files on the host machine.
I solved this problem by copying the two executables to an Android device (Samsung Galaxy S III) using scp and the SSHDroid application, and generating the two header files there:

$ jscpucfg > jsautocfg.h
$ jskwgen > jsautokw.h

then I copied the two files back to my node on my Ubuntu machine and saved in the source trunk under the config sub-directory. Then I changed the makefile to skip generating these two header files when cross-compiling for Android and get them instead from the config sub-directory.
The SpiderMonkey jsnum.c file generates the following error when cross-compiled for Android:

js-1.7/jsnum.c: In function 'js_InitRuntimeNumberState':
js-1.7/jsnum.c:578: error: 'struct lconv' has no member named 'thousands_sep'
js-1.7/jsnum.c:578: error: 'struct lconv' has no member named 'thousands_sep'
js-1.7/jsnum.c:580: error: 'struct lconv' has no member named 'decimal_point'
js-1.7/jsnum.c:580: error: 'struct lconv' has no member named 'decimal_point'
js-1.7/jsnum.c:582: error: 'struct lconv' has no member named 'grouping'
js-1.7/jsnum.c:582: error: 'struct lconv' has no member named 'grouping'
gmake[2]: *** [js-1.7.dir/jsnum.c.o] Error 1

This is caused by the fact that the lconv structure in locale.h shipped with the Android NDK is stubbed with the following comment:

#if 1 /* MISSING FROM BIONIC - DEFINED TO MAKE libstdc++-v3 happy */
struct lconv { };
struct lconv *localeconv(void);
#endif /* MISSING */

To solve this problem I applied the following patch to jsnum.c and I was able to successfully cross-compile SpiderMonkey 1.7 for Android.

--- a/jsnum.c   2013-01-10 10:37:54.413800695 -0500
+++ b/jsnum.c   2013-01-10 10:06:49.432752061 -0500
@@ -573,13 +573,28 @@ js_InitRuntimeNumberState(JSContext *cx)
     u.s.lo = 1;
     number_constants[NC_MIN_VALUE].dval = u.d;

-    locale = localeconv();
-    rt->thousandsSeparator =
-        JS_strdup(cx, locale->thousands_sep ? locale->thousands_sep : "'");
-    rt->decimalSeparator =
-        JS_strdup(cx, locale->decimal_point ? locale->decimal_point : ".");
-    rt->numGrouping =
-        JS_strdup(cx, locale->grouping ? locale->grouping : "\3\0");
+    /* Copy locale-specific separators into the runtime strings. */
+    const char *thousandsSeparator, *decimalPoint, *grouping;
+#ifdef HAVE_LOCALECONV
+    locale = localeconv();
+    thousandsSeparator = locale->thousands_sep;
+    decimalPoint = locale->decimal_point;
+    grouping = locale->grouping;
+#else
+    thousandsSeparator = getenv("LOCALE_THOUSANDS_SEP");
+    decimalPoint = getenv("LOCALE_DECIMAL_POINT");
+    grouping = getenv("LOCALE_GROUPING");
+#endif
+    if (!thousandsSeparator)
+        thousandsSeparator = "'";
+    if (!decimalPoint)
+        decimalPoint = ".";
+    if (!grouping)
+        grouping = "\3\0";
+
+    rt->thousandsSeparator = JS_strdup(cx, thousandsSeparator);
+    rt->decimalSeparator = JS_strdup(cx, decimalPoint);
+    rt->numGrouping = JS_strdup(cx, grouping);

     return rt->thousandsSeparator && rt->decimalSeparator && rt->numGrouping;
}

Of course you would define HAVE_LOCALECONV only for regular builds but not for Android cross-compilations, so that you could either pass your own definitions for the locale thousands separator, decimal point or locale grouping via environment variables, or use the above defaults.

How to inspect expanded C macros with gcc/gcc+

2013-01-09T15:04:00.000-05:00

Sometimes you get compilation errors in gcc/g++ and you'd like to inspect the output from the C compiler pre-processor to figure out why certain macros were expanded in such as way to cause an error.
The solution is simply to remove the -o and -c options from your gcc/g++ command line and replace it with

gcc/g++ -E -dD

this will generate on your terminal only the C pre-processor output that is eventually fed to the C/C++ compiler.

For example you are trying to compile Mozilla SpiderMonkey 1.7 and one of the compiler lines is the following:

/usr/bin/gcc  -Djs_1_7_EXPORTS -DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DHAVE_LOCALTIME_R -DX86_LINUX -D_IEEE_LIBM -DJS_EDITLINE -DEDITLINE -DHAVE_VA_COPY -DVA_COPY=va_copy -DPIC -DANSI_ARROWS -DHAVE_TCGETATTR -DHIDE -DUSE_DIRENT -DSYS_UNIX -DHAVE_STDLIB -DUNIQUE_HISTORY -O3 -DNDEBUG -fPIC -I../js-1.7  -fPIC -o CMakeFiles/js-1.7.dir/jsarena.c.o   -c js-1.7/jsarena.c

To see the expanded C macros run the following command:

/usr/bin/gcc -E -dD -Djs_1_7_EXPORTS -DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DHAVE_LOCALTIME_R -DX86_LINUX -D_IEEE_LIBM -DJS_EDITLINE -DEDITLINE -DHAVE_VA_COPY -DVA_COPY=va_copy -DPIC -DANSI_ARROWS -DHAVE_TCGETATTR -DHIDE -DUSE_DIRENT -DSYS_UNIX -DHAVE_STDLIB -DUNIQUE_HISTORY -O3 -DNDEBUG -fPIC -I../js-1.7 -fPIC js-1.7/jsarena.c

Upgrading mid-2007 24in iMac with an SSD and a 2.5in HDD in the optical bay

2013-01-06T21:40:00.001-05:00

I own a mid-2007 24in iMac with a 2.4 GHz Intel Core 2 Duo processor, 4GB of DDR2 DRAM, running Mac OS Mountain Lion, and for the past few months the computer was getting slower and slower, and when I was running Windows XP in VMWare Fusion, the machine was often swapping, bringing the iMac to a crawl. Finally I decided to upgrade my iMac by installing an SSD. Two years ago I replaced the Western Digital 500 GB hard drive (that failed on me one day by giving me the gray screen of death at boot time), with a 1 TB WD caviar green which I almost filled since then (about 750 GB used).
So I wanted the fast SSD drive but also to maintain the 1 TB of space available. The solution I adopted (found on several posts on the internet) was to replace the existing SATA HDD with an SSD, and replace the optical drive with a PATA to SATA adapter hosting a 2.5in HDD. To avoid the swapping I also replaced one of the 2 GB memory modules with a new OWC 4GB module, bringing the total available memory to 6GB.

Hardware Parts

This is the list of hardware components I ended up buying for this upgrade:

Hardware Installation

Here is the picture of the tools I used to perform the upgrade (grounding wrist band, 6 Pc. mini torx screwdriver set, spudgers, vacuum cups, philips screwdriver.

I followed the instructions to replace the hard drive and the optical bay from the iFixit web site.
The following picture shows the iMac internal components.

The old 1TB caviar green HDD is shown in the following picture. The idea was to replace it with the SSD mounted on the 2.5'' to 3.5'' bay converter.

This picture shows instead the Apple optical drive (superdrive).

I removed the optical drive and replaced it with the 1TB WD Blue HDD mounted on the MCE OptiBay enclosure as shown in the following picture. I also put a piece of foam in the enclosure gap (top of picture) to prevent the HDD from moving.

Then I installed the Crucial M4 SSD inside the SilverStone 2.5" to 3.5" Bay Converter in the bottom position (there is room to install two SSD or two 2.5'' HDD), in order to align the SATA and power connectors with the iMac motherboard.

The following picture shows the newly installed SSD on the top left, and the WD Blue HDD inside the OptiBay enclosure on the bottom right. Notice I attached the thermal sensor for the SSD directly on the metal frame of the bay converter, and used tape to make sure it stays in position.

All the hardware parts described above fitted perfectly in my iMac and I didn't have to do anything special to install them except for adding the piece of foam in the OptiBay enclosure to prevent the HDD from moving around.

Software Configuration

At this point my iMac had two new unformatted disk drives and my original HDD was sitting on my desk. What I had in mind was to install Mac OS on the Crucial M4 SSD, and put the users on the WD Blue HDD. In fact 64 GB are not enough to store the users directories where for example pictures and movies take a lot of disk space. To restore the system I then followed this procedure.

I took the original WD caviar green HDD and installed it in a Rosewill external SATA enclosure I had laying around. Then I connected the external SATA enclosure to the iMac via an USB cable.
I powered up the iMac holding the option button. This gave me the option to boot into Mountain Lion from the external WD Caviar Green HDD (volume name Macintosh HD).
I logged in and opened the Disk Utility application. Selected the Crucial M4 disk, clicked on the Erase tab and formatted the disk by selecting the Mac OS Extended (journaled) format and naming the volume Macintosh SSD.
In a similar way I erased the WD Blue HD disk and named the volume Macintosh HD Users. At the end of this procedure, Disk Utility showed the following on the screen:

Then I ran Carbon Copy Cloner and copied all directories from the external Macintosh HD except the /Users directory to the Crucial M4 on volume Macintosh SSD (it is simple to do this since Carbon Copy Cloner allows you to select individual directories to copy from the source). I ended up copying about 32 GB to the Macintosh SSD volume, which took about 1 hour.

I ran Carbon Copy Cloner again but this time for source I selected the /Users directory only from the external Macintosh HD, and Macintosh HD Users for destination. To copy 693 GB Carbon Copy Cloner took about 7 hours and 47 minutes.
(If you don't want to use Carbon Copy Cloner, you can copy the files directly using the ditto command. For example to clone the /Users directory:

# sudo ditto /Volumes/Macintosh\ HD/Users /Volumes/Macintosh\ HD\ Users/Users/
)

I then opened the Terminal app, logged in as root and created a symbolic link to the new location of the /Users directory:

# sudo su -
# cd /Volumes/Macintosh\ SSD

# ln -s /Volumes/Macintosh\ HD\ Users/Users/ Users

At this point I rebooted the iMac and when it came back all my original logins with their setting were magically preserved. MacOSX now boots in 13 seconds, and opening applications is almost instantaneous. Now I still had to do some tweaks to make the new setup even better. I followed the suggestion from Martin's blog (Optimizing MacOS X Lion for SSD).

I went to System Preferences, clicked on Users & Groups, clicked the lock icon to unlock the advanced editing. Once unlocked, I right-clicked on each user account and chose Advanced Options from the pop-up menu. Once in the Advanced Options dialog, I changed the Home directory of the user from /Users/user-name to the new location (/Volumes/Macintosh\ HD\ Users/Users/user-name).
I installed and enabled TrimEnabler from this web site.
I set the noatime flag to prevent MacOS from updating the SSD file system every time a file is accessed.
I used the WD Blue HDD for temporary files.

sudo ditto /private/tmp /Volumes/Macintosh\ HD\ Users/private/tmpsudo rm -rf /private/tmpsudo ln -s /Volumes/Macintosh\ HD\ Users//private/tmp /private/tmp

I rebooted the iMac another time and verified that Trim was working, the root file system was mounted with the noatime flag and that temporary files were going to the HDD drive instead of the SSD.

Given new life to an old machine. I'm pretty happy now.

How to Cross-Compile libiconv for Android

2012-12-18T14:57:00.003-05:00

If your legacy C/C++ code includes <iconv.h> to convert the encoding of characters from one coded character set to another, and you need to cross-compile it with the Android NDK, you will get the following error:

   error: iconv.h: No such file or directory

In fact there is currently no iconv.h available in the Android NDK and you will have to port libiconv to Android yourself.
I successfully used the following instructions to cross-compile libiconv.so for Android.

Get the source code for libconv-1.13.1:

   $ wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz

Unzip and untar the file:

   $ tar zxvf libiconv-1.13.1.tar.gz

Patch localcharset.c using the following patch file (or else you will get another error: : langinfo.h: No such file or directory) :

   $ echo "diff --ignore-file-name-case -wuprN libiconv-1.13.1.orig/libcharset/lib/localcharset.c libiconv-1.13.1/libcharset/lib/localcharset.c

--- libiconv-1.13.1.orig/libcharset/lib/localcharset.c  2009-06-21 07:17:33.000000000 -0400

+++ libiconv-1.13.1/libcharset/lib/localcharset.c       2012-12-18 10:20:27.000000000 -0500

@@ -44,7 +44,7 @@

 # endif

 #endif

-#if !defined WIN32_NATIVE

+#if !defined(WIN32_NATIVE) && !defined(__ANDROID__)

 # if HAVE_LANGINFO_CODESET

 #  include <langinfo.h>

 # else

@@ -328,7 +328,7 @@ locale_charset (void)

   const char *codeset;

   const char *aliases;

-#if !(defined WIN32_NATIVE || defined OS2)

+#if !(defined WIN32_NATIVE || defined OS2 || defined __ANDROID__)

 # if HAVE_LANGINFO_CODESET " > iconv.patch

   $ patch -b -p0 < ./iconv.patch

Run the configure script and generate iconv.h:

   $ cd libiconv-1.13.1

   $ ./configure

Create a jni sub-directory:

$ mkdir jni

And save the following lines in jni/Android.mk:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
TARGET_ARCH_ABI := armeabi-v7a
LOCAL_MODULE    := iconv
LOCAL_CFLAGS    := \
    -Wno-multichar \
    -D_ANDROID \
    -DLIBDIR="\"c\"" \
    -DBUILDING_LIBICONV \
    -DIN_LIBRARY
LOCAL_C_INCLUDES := \
    ../libiconv-1.13.1 \
    ../libiconv-1.13.1/include \
    ../libiconv-1.13.1/lib \
    ../libiconv-1.13.1/libcharset/include
LOCAL_SRC_FILES := \
    ../libiconv-1.13.1/lib/iconv.c \
    ../libiconv-1.13.1/lib/relocatable.c \
    ../libiconv-1.13.1/libcharset/lib/localcharset.c
include $(BUILD_SHARED_LIBRARY)

Finally cross-compile iconv using the ndk-build tool:

   $ cd jni

   $ ndk-build V=1

If everything goes well, you will find iconv.h under libiconv-1.13.1/include and libiconv.so under libs/armeabi.

Configuring the Apple Airport Extreme with Verizon FIOS

2012-12-04T22:51:00.004-05:00

I have Verizon FIOS triple-play service and I love the TV picture quality and internet speed and reliability, but I don't like Verizon's solution to my Parental Control needs.
So I've decided to buy an Airport Extreme Base Station (AEBS) from Apple, but when I went to set it up, it configured itself for bridged mode since the Verizon modem is also a router and the Airport Utility decided not to have a double NAT configuration. Anyway by doing so you loose the capability of having a guest network with the Airport Extreme since it dummies itself down from a full fledged router to a simple level-2 switch.
So I managed to manually set it up in DHCP/NAT mode even though it is initially complaining about a double NAT configuration (one from the Verizon router and one from the AEBS), but least I gained my guest network back (at the time of this post it is not possible to configure a guest network with the Verizon router).

Hardware Configuration

Apple Router: AirPort Extreme Base Station, Part Number: MD031LL/A

Verizon Modem/Router: Actiontec MI424WR Rev. I

I used a CAT6 Patch cable to connect the AEBS Internet WAN port to Ethernet Port 1 of the Actiontec. This setting allows the two routers to communicate at wire speed of up to 1 GB per second.

Software Configuration

Here is the step by step procedure to set up the Airport Extreme I ran from an iMac running Mountain Lion.

Click on the picture of the Airport Extreme base station: a popup window will show an Edit button
Click on the Edit button
Click on the Network tab and select "DHCP and NAT" from the Router Mode
Click on the Network Options button and select "10.0" for the IPv4 DHCP Range, and "172.16" for the Guest IPv4 DHCP Range. Click on the Save button (see picture below)

Click on the Update button: this will reset the AEBS and cause a solid yellow light with a status of Double NAT. The AEBS will advise you to switch back to bridge mode
Click on the Double NAT Status pull-down menu and select Ignore: after another reboot the AEBS should come up with a solid green color

Regarding the Actiontec configuration, I left it as is, except for disabling the wireless mode to avoid interference with the AEBS.

With an internet browser log on to http://192.168.1.1 using the login and password printed on the bottom of the MI424WR modem/router.
Click on the Wireless Settings icon:

Wireless
Settings

Click on Basic Security Settings from the left panel
Click on Off from the 1. Turn Wireless ON form entry
Click on the Apply button to disable wireless

Considerations

Having the Verizon DHCP server using the 198.168.1.xxx IP addresses range and the AEBS the 10.0.1.xxx range will keep you sane and prevent confusions in your mind about which sub-network you are connected to.
In any case these two sub-networks are completely separated and invisible from the Internet and you cannot have a device connected to one subnet talk to another device on the other subnet (unless you start configuring forwarding ports on the AEBS of course). This is OK since I plan to keep all of my computers and devices on the subnet controlled by the AEBS in order to have access control over each device.
To my disappointment the Airport Utility version 6.1 used to configure the AEBS is probably one the worst application I ever used to set up a router. It's not intuitive and worst of all it doesn't show who's connected to your network (or at least it doesn't show all the connected devices). In fact it only shows wireless clients in a weird fashion (by hovering over the base station picture), but no sign of any device connected through the Gigabit ethernet ports. By the way the list of wireless client is dynamic and you cannot even copy/paste the MAC addresses to add later to the access control table. I ended up switching to the previous version of Airport Utility (version 5.6 - as suggested by several people on the Internet) since with that you can still get a list of all devices connected to the AEBS from the Advanced->Logs and Statistics->DHCP Clients tab.

Still for parental control AEBS only has a time-based table where you can setup a schedule on a per MAC address basis. So I still had to resolve the problem of preventing my kids from hitting questionable web sites. I solved that by setting the OpenDNS servers for primary and secondary DNS servers in my Verizon router. OpenDNS offer a basic parental control filter based on categories. But I found that is is adequate for my needs.

Python For Android (Py4A)

2012-11-20T10:01:00.002-05:00

A better solution for cross-compiling Python for Android is to use the Py4A project which is made to be used together with SL4A (Scripting Layer For Android). If you are only interested in the Python interpreter and the runtime Python library, you can also use it standalone.
Get a local copy of the source code using the following command:

$ hg clone https://code.google.com/p/python-for-android/

Just focus on the python-build subdirectory and make sure the python-build/python-src subdirectory is not present (remove it if it came with the Mercurial repository, or else the compilation will fail).
Set up your environment so that the python-for-android build script can pick up the ndk-build script from the Android NDK:

$ export ANDROID_NDK_ROOT=/home/<your-directory>/android-ndk-r8
$ export PATH=$ANDROID_NDK_ROOT:$PATH

Finally build Python for Android by issuing the following command:

  $ cd python-for-android/python-build

$ rm -rf python-src
$ bash build.sh

Note that on my Ubuntu 12.04 machine I had initially the following compilation error:

Traceback (most recent call last):
File "build.py", line 161, in <module>
    os.path.join(pwd, 'output.temp', 'usr'))
File "build.py", line 89, in zipup
    zip_file = zipfile.ZipFile(out_path, 'w', compression=zipfile.ZIP_DEFLATED)
File "/home/danilo/python-for-android/python-build/host/lib/python2.6/zipfile.py", line 660, in __init__
    "Compression requires the (missing) zlib module"
RuntimeError: Compression requires the (missing) zlib module

I identified the problem in having the zlib library in my system installed under /lib/x86_64-linux-gnu/ instead of one of the traditional lib directories covered by the Python setup.py script. Also on my system I only had libz.so.1 and not libz.so. So to fix both problems I just created a symlink in the standard /usr/lib directory as follows:

  $ cd /usr/lib

$ sudo ln -s /lib/x86_64-linux-gnu/libz.so.1 libz.so

With this fix the build.sh script was able to successfully build the zlib module for the host environment and create the following zipped files:

python_extras_r14.zip
python-lib_r16.zip
python_r16.zip
python_scripts_r13.zip

Of these I only used the python_r16.zip which contains the stripped python interpreter and the runtime libraries, and the python-lib_r16.zip which contains the include header files such as Python.h that can be used to compile Python bindings at development time.

Arduino and 7-segment LED counter driven by two tactile switches

2012-11-05T17:16:00.000-05:00

I have posted on YouTube a couple of videos about a project I made with the Arduino prototype board. The circuit uses an Arduino mini and has a simple gear counter based on a 7-segment LED and controlled by two switches. It can be mounted on your bike and used for example to visualize which gear you are in at any time.

If you are interested in the schematics I have the PCB Artist version downloadable here:

The Arduino code is instead available below.

/*
  Blink
 
 Turns on an LED on for one second, then off for one second, repeatedly.
 
 The circuit:
 * LED connected from digital pin 13 to ground.
 
 * Note: On most Arduino boards, there is already an LED on the board
 connected to pin 13, so you don't need any extra components for this example.
 
 
 Created 1 June 2005
 By David Cuartielles
 
 http://arduino.cc/en/Tutorial/Blink
 
 based on an orginal by H. Barragan for the Wiring i/o board
 
 */

#define BUTTON_DOWN 10
#define BUTTON_UP 12

int ledPinA =  6;    // LED connected to digital pin 3
int ledPinB =  9;    // LED connected to digital pin 4
int ledPinC =  4;    // LED connected to digital pin 5
int ledPinD =  3;    // LED connected to digital pin 6
int ledPinE =  2;    // LED connected to digital pin 7
int ledPinF =  7;    // LED connected to digital pin 8
int ledPinG =  8;    // LED connected to digital pin 9
int ledPinDP =  5;   // LED connected to digital pin 10

int val_down = 0;
int old_val_down = 0;
int val_up = 0;
int old_val_up = 0;
int state = 0;
int gear = 1;

// The setup() method runs once, when the sketch starts

void setup()   {             
  pinMode(BUTTON_DOWN, INPUT);
  pinMode(BUTTON_UP, INPUT);
  
  // initialize the digital pin as an output:
  pinMode(ledPinA, OUTPUT);
  pinMode(ledPinB, OUTPUT);
  pinMode(ledPinC, OUTPUT);
  pinMode(ledPinD, OUTPUT);
  pinMode(ledPinE, OUTPUT);
  pinMode(ledPinF, OUTPUT);
  pinMode(ledPinG, OUTPUT);  
  pinMode(ledPinDP, OUTPUT);
  
  // initialize serial communication:
  Serial.begin(9600);
}

void led0()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, LOW);  
  digitalWrite(ledPinF, LOW);  
  digitalWrite(ledPinG, HIGH); 
  digitalWrite(ledPinDP, HIGH);
}

void led1()
{
  digitalWrite(ledPinA, HIGH);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, HIGH);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, HIGH);  
  digitalWrite(ledPinG, HIGH); 
  digitalWrite(ledPinDP, HIGH);
}

void led2()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, HIGH);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, LOW);  
  digitalWrite(ledPinF, HIGH);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
}

void led3()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, HIGH);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
}

void led4()
{
  digitalWrite(ledPinA, HIGH);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, HIGH);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, LOW);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
} 

void led5()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, HIGH);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, LOW);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
} 

void led6()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, HIGH);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, LOW);  
  digitalWrite(ledPinF, LOW);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
} 

void led7()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, HIGH);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, HIGH);  
  digitalWrite(ledPinG, HIGH); 
  digitalWrite(ledPinDP, HIGH);
} 

void led8()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, LOW);  
  digitalWrite(ledPinF, LOW);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
} 

void led9()
{
  digitalWrite(ledPinA, LOW);
  digitalWrite(ledPinB, LOW);
  digitalWrite(ledPinC, LOW);
  digitalWrite(ledPinD, LOW);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, LOW);  
  digitalWrite(ledPinG, LOW); 
  digitalWrite(ledPinDP, HIGH);
} 

void ledDP()
{
  digitalWrite(ledPinA, HIGH);
  digitalWrite(ledPinB, HIGH);
  digitalWrite(ledPinC, HIGH);
  digitalWrite(ledPinD, HIGH);
  digitalWrite(ledPinE, HIGH);  
  digitalWrite(ledPinF, HIGH);  
  digitalWrite(ledPinG, HIGH); 
  digitalWrite(ledPinDP, LOW);
} 

void setLed(int number)
{
  switch (number) {
    case 0:  
      ledDP();
      break;
    case 1:  
      led1();
      break;
    case 2:  
      led2();
      break;
    case 3:  
      led3();
      break;
    case 4:  
      led4();
      break;
    case 5:  
      led5();
      break;
    case 6:  
      led6();
      break;
    case 7:  
      led7();
      break;
    case 8:  
      led8();
      break;
    case 9:  
      led9();
      break;
  }
}
              
// the loop() method runs over and over again,
// as long as the Arduino has power

void oldloop()                     
{
  ledDP();
  delay(1000);                  // wait for a second
  led0();
  delay(1000);                  // wait for a second
  led1();
  delay(1000);                  // wait for a second
  led2();
  delay(1000);                  // wait for a second
  led3();
  delay(1000);                  // wait for a second
  led4();
  delay(1000);                  // wait for a second
  led5();
  delay(1000);                  // wait for a second
  led6();
  delay(1000);                  // wait for a second
  led7();
  delay(1000);                  // wait for a second
  led8();
  delay(1000);                  // wait for a second
  led9();
  delay(1000);                  // wait for a second
}

void loop()
{
    val_up = digitalRead(BUTTON_UP);
    if ((val_up == HIGH) && (old_val_up == LOW)) {
      gear += 1;
      Serial.print("gear number:  ");
      Serial.println(gear, DEC);
      delay(100);
    }
    old_val_up = val_up;
 
    val_down = digitalRead(BUTTON_DOWN);
    if ((val_down == HIGH) && (old_val_down == LOW)) {
      gear -= 1;
      Serial.print("gear number:  ");
      Serial.println(gear, DEC);
      delay(100);
    }
    old_val_down = val_down;
    
    if (gear >= 6) {
      gear = 6;
    }
    if (gear <= 1) {
      gear = 1;
    }
    
    setLed(gear);
}

How to cross-compile Python for Android

2012-10-26T10:51:00.000-04:00

When it comes to cross-compiling Python for Android, I've followed Gabriel's blog post @ http://mdqinc.com/blog/2011/09/cross-compiling-python-for-android/ and I was successful in creating an Arm-based Python executable (and related libraries) in little or no time.
Gabriel has a lot of the initial steps just verbally described, but I've come up with a shell script that allows you to automate the entire process. Of course you need to replace <path-to-android-ndk> with the directory where you have installed the NDK.
Here it goes.

ANDROID_NDK=<path-to-android-ndk>
ANDROID_ABI="armeabi-v7a"
ANDROID_NATIVE_API_LEVEL="android-8"
PYTHON_VERSION="2.6.2"

output_dir=$1
mkdir -p $output_dir
cd $output_dir
# get Python source tarball
wget http://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tgz

# create Python Host version
tar zxvf Python-$PYTHON_VERSION.tgz
mv Python-$PYTHON_VERSION Host-Python-$PYTHON_VERSION-src
cd Host-Python-$PYTHON_VERSION-src
./configure --prefix=$output_dir/Host-Python-$PYTHON_VERSION
make
make install

cd $output_dir
# create Python Cross-compiled version for Android
tar zxvf Python-$PYTHON_VERSION.tgz
mv Python-$PYTHON_VERSION Android-Python-$PYTHON_VERSION-src
cd Android-Python-$PYTHON_VERSION-src

# get and apply Python patch
wget -o Python-2.6.2-android.patch https://sites.google.com/site/dgtechblogscripts/Python-2.6.2-android.patch
patch -p0 < Python-2.6.2-android.patch
# fix setup.py
mv setup.py setup.py.orig
cat setup.py.orig | awk '{ if (NR==316) {print " " $0} else {print $0}}' > setup.py

MY_HOSTPYTHON=$output_dir/Host-Python-$PYTHON_VERSION/bin/python
MY_HOSTPGEN=$output_dir/Host-Python-$PYTHON_VERSION-src/Parser/pgen

export ANDROID_NDK
export PATH="$ANDROID_NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/:$ANDROID_NDK:$ANDROID_NDK/tools:/usr/local/bin:/usr/bin:/bin"
export ARCH=$ANDROID_ABI
export CFLAGS="-DANDROID -mandroid -fomit-frame-pointer --sysroot $ANDROID_NDK/platforms/$ANDROID_NATIVE_API_LEVEL/arch-arm"
export CXXFLAGS="$CFLAGS"
export CC="arm-linux-androideabi-gcc $CFLAGS"
export CXX="arm-linux-androideabi-g++ $CXXFLAGS"
export AR="arm-linux-androideabi-ar"
export RANLIB="arm-linux-androideabi-ranlib"
export STRIP="arm-linux-androideabi-strip --strip-unneeded"
export MAKE="make -j4 install HOSTPYTHON=$MY_HOSTPYTHON HOSTPGEN=$MY_HOSTPGEN CROSS_COMPILE=arm-eabi- CROSS_COMPILE_TARGET=yes"

./configure LDFLAGS="-Wl,--allow-shlib-undefined" CFLAGS="-mandroid -fomit-frame-pointer --sysroot $ANDROID_NDK/platforms/$ANDROID_NATIVE_API_LEVEL/arch-arm" HOSTPYTHON=$MY_HOSTPYTHON HOSTPGEN=$MY_HOSTPGEN --host=arm-eabi --build=i686-pc-linux-gnu --enable-shared --prefix="$output_dir/Android-Python-$PYTHON_VERSION"
sed -i "s|^INSTSONAME=$.*.so$.*|INSTSONAME=\\1|g" Makefile
$MAKE

Installing the Android NDK

2012-10-26T10:36:00.000-04:00

These instructions refer to a Ubuntu 12.04.1 LTS system running on an Intel processor.

Head to the http://developer.android.com/tools/sdk/ndk/index.html web site and download the latest version of the Android NDK for Linux (release r8b for example):
```
$ wget http://dl.google.com/android/ndk/android-ndk-r8b-linux-x86.tar.bz2
```

Unzip and untar the downloaded file in your preferred directory:

$ bunzip2 android-ndk-r8b-linux-x86.tar.bz2
$ tar zxvf android-sdk_r20.0.3-linux.tgz

You should now have a directory called android-ndk-r8b containing release 8b of the Android NDK.

Problems with new version of rpmbuild

2012-10-11T14:50:00.001-04:00

The Problem

With the new version of rpmbuild installed on CentOS 6.x, if you try to use an old RPM spec file, you will get an error like the following:

error: File not found: <path>/BUILDROOT/<product>-6.7.x86_64/<filename>

Previously rpmbuild would install and look for files under the rpm_top/BUILD directory, while now it looks under the new BUILDROOT directory.

The Solution

This is what I ended up doing to solve the problem. When I call rpmbuild I now define a new variable, for example:

$ centos_release=$(lsb_release -rs | sed 's/\.//')

$ rpmbuild --define "centos_release $centos_release" ... -bb specfile

then I changed my spec file to contain something like the following:

%if %{centos_release} >= 60


%setup -q -c -n %{buildroot}/usr/local/ 
cp -a -r %{buildroot}/usr/local/ /usr/

%else

%setup -q -c -n usr/local/
%install
cp -a -r $PWD /usr/

%endif

Another related problem

Suppose you have a single tar ball and you want to create two or more RPMs using different spec files. The new version of rpmbuild automatically cleans the BUILDROOT directory after completing the targets for a given spec file. If you want to save time and have the second spec file just look for the BUILDROOT created by the first spec it won't find it because of the automatic clean. So it seems like you are forced to untar and install under the BUILDROOT your file over and over again.
A simple solution to this problem is to add a %clean directive to your spec file and do nothing to disable to automatic cleaning done by rpmbuild. Add the following line at the bottom of your spec file:

%clean

Installing the Android SDK

2012-10-08T16:16:00.001-04:00

These instructions refer to a Ubuntu 12.04.1 LTS system running on an Intel processor.

Head to the developer.android.com web site and download the latest version of the Android SDK for Linux (release 20.0.3 for example): http://dl.google.com/android/android-sdk_r20.0.3-linux.tgz
Untar the downloaded file in your preferred directory:
```
$ tar zxvf android-sdk_r20.0.3-linux.tgz
```

You should now have a directory called android-sdk-linux containing release 20.0.3 of the Android SDK.

Porting your Legacy C/C++ project to Android

2012-10-06T20:49:00.000-04:00

This is a recurring problem people have often: trying to port a big C/C++ project to the Android platform. You have thousands of lines of tested and working C/C++ code that you want to reuse and access from your Android application. So far Android only provides an SDK for Java applications, only supports devices with ARM, MIPS and x86 architectures, and several steps are necessary if you want to port your code and call it from Java as a library. By large the biggest deployment is for ARM processor devices, so we are initially focused on porting our code to this architecture.
Porting your C/C++ project to the Android platform entails then the following steps:

Cross-compile the C/C++ code for the ARM processor (or any other supported) architecture.
Develop a JNI module allowing an Android application to natively call the C/C++ code from Java.
Develop an Android application using the JNI module.
Run and debug the app on an Android device.

Developing an Android application requires the Android Software Development Kit (SDK), while cross-compiling your C/C++ code and developing the JNI module for Android requires the Android Native Development Kit (NDK). Both these kits run on Windows XP/Win7, Mac OS 10.5.8 or later (Intel), or Ubuntu Linux 8.04 or later.

My intention is to publish on this blog several posts with detailed instructions on how to accomplish the above mentioned steps. The instructions are based on other posts you can search on the internet and on my experience with Android. All the instructions are based on the development and testing environments described below.

Development Environment

Processor: Intel(R) Core(TM) 2 Duo CPU E8600 @ 3.33GHz
RAM: 4GB DDR2 SDRAM DIMM 240-pin
OS: Ubuntu Linux 12.04
Eclipse IDE Juno
Android SDK r20
Android NDK r8

Testing Environment

LG Thrill 4G - Android 2.2
Samsung Galaxy Tab 8.9 - Android 3.2
Samsung Galaxy Tab 2 7.0 - Android 4.01
Samsung Galaxy S III - Android 4.0.4

Transferring Files from a computer to your Android device

2012-10-06T12:32:00.002-04:00

Android devices have file systems similar to regular computers. Subject to permissions restrictions, we can transfer files from a computer to a device (connected to the computer by USB) or emulator, or from the device or emulator to the computer. There are several ways to transfer files to an Android device:

Using Eclipse
Select the DDMS perspective for Eclipse and use the File Explorer tab to select the directory where you want to tranfer a file to (a drawback of using this method is that you can only tranfer one file at a time).
Using the ADB
You can tranfer entire directories using the ADB command line interface. For example to transfer the entire content of a director to an Android device connected to a Ubuntu computer via the USB port:
```
$ adb push <path to directory to copy> /mnt/sdcard/<target directory>
```
Install an ssh daemon on the Android device and then use sftp from your workstation. For example you can download the free SSHDroid app from the Google market and install it on your device, run the app an find out about the IP address to connect to. Then from a terminal window in Linux you can connect like this (works on Ubuntu 12.04):
```
$ ssh -p 2222 root@ip-address-mentioned-in-SSHDroid
```

Danilo's Tech Blog

This blog has moved!

Simplified script to cross-compile Python-4-Android for both ARM NEON and x86

Cross-compiling Python-4-Android for ARM NEON

Cross-compiling Python-4-Android for x86

ndk-gdb error: Could not extract package's data directory. Are you sure that your installed application is debuggable?

The Problem

The Solution

Once upon a time there were Bell Labs...

How to debug Android Native Code with Eclipse

1. Pre-Requisites

1.1. Install the Eclipse Sequoyah plugin

1.2. Convert The Android Java Application into C/C++ Project

1.3. Other Pre-Requisites

2. Configurations

3. Instructions

How to compile libogg for Android

How to compile busybox with Android NDK for both ARM and x86 architectures

Cross-compiling busybox with the Android NDK

Download busybox binaries

Installing busybox

Pre-requisites

Installation Procedure

How to build the gcc Fortran cross-compiler for Android (ARM and x86)

Addendum of August 30, 2013

How to root Motorola RAZRi XT890 running Android 4.0.4

You need to download the Android SDK

Install the latest Motorola USB drivers for you phone

Your phone should be factory unlocked

Root the device

How to build Python-4-Android for the ARM Neon

How to build Python-4-Android for the x86

Android: Trying to load native library results in a process terminated by signal (11)

Symptoms

Causes

Solution

How to port Mozilla SpiderMonkey 1.7 to Android

How to inspect expanded C macros with gcc/gcc+

Upgrading mid-2007 24in iMac with an SSD and a 2.5in HDD in the optical bay

Hardware Parts

Hardware Installation

Software Configuration

How to Cross-Compile libiconv for Android

Configuring the Apple Airport Extreme with Verizon FIOS

Hardware Configuration

Software Configuration

Considerations

Python For Android (Py4A)

Arduino and 7-segment LED counter driven by two tactile switches

How to cross-compile Python for Android

Installing the Android NDK

Problems with new version of rpmbuild

The Problem

The Solution

Another related problem

Installing the Android SDK

Porting your Legacy C/C++ project to Android

Development Environment

Testing Environment

Transferring Files from a computer to your Android device