How Compile Android Goldfish Kernel on Windows OS

This article will chronicle the events that happening during the session of compiling Android Goldfish kernel on windows environment. It is hoped that by the end of this article, you can also repeat this experiment successfully.

Host machine is Windows 7, with installed MINGW GCC 4.7.2 and latest version of CYGWIN. The goldfish kernel source already has the makefile, so it seems do not requires the configuration phase.

After everything is ready, kernel configuration phase is done by calling the make as follows:


The first impression is the crashed GCC compiler as informed by the OS:


To perform tracking of the above error message, it is necessary to creates basic framework to print-out processed value into the make log file. This is done by creating basic script as follows:


Using the above construct, the output when done using -p command:


The output will show:


So, the causes of the above crash is originated from script execution of:


After isolating the execution script inside the above makefile, I arrived at one of the many troubling scripts that has patterns as follows:


Which calls to cc-option in Kbuild.include with the prototype as follows:


And the try-run function as follows:


The above scripts try to probe the compiler for presence of specific compiler flags, and perform necessary setup for the starting the compilation phase.

The above constructs will causes the compiler to crash, but, what exactly the cause of this ? To perform more examination, I’ve created the test script (let’s call it testmk) that contains the related functions and try to simplifies the output and do not perform any silencing options as follows:


Here is the output when the above script is executed:


After the above message, the compiler will try to find non-existent file and will caused it to crash. Hence the above crash message box is shown.

So, the problems is malformed temporary file name string. After trying some ways to fix this without success, I decided to evade the using of temporary file inside the shell chain of command. Instead, I’m using the temporary file outside the the call. For example as follows:


Then the script temporary file creation is removed to become:


The crashes is now gone, but I arrived at another error as follows:


This is because there’s a command in the makefile script as follows (by viewing the myTesting.txt file):


Which translates to (using procmon.exe):


Functions inside fixdep.c is specific to Linux OS and MINGW still can’t handle it, so it is necessary to use Cygwin’s compiler instead of MINGW GCC by modifying the makefile scripts at specific location (in This should be done for other host specific programs:


Re-run the make program, the configuration phase seems to work, Now:


This is because the ln.exe in MSYS is broken, so after I use the alternate one in Cygwin the symbolic link sucessfully created. Now, I have:


This is because compiled dependency file created by arm compiler on windows contains CR (Carriage Return) characters, so fixdep.c is broken because in its native environment do not recognize CR character, so perform small changes to the source will fix this. Now I have:


Now the make script complained that it can not create the file inside include/asm. Seems that the symbolic link is created all right but it is useless, because Windows OS do not recognize it.

What’s the solution ? I should use the native command of windows MKLINK and remove the previously written symbolic link:


But now the make scripts complains that ERROR: $@ is a directory but a symlink was expected, which is contrary to the philosophy of current situatuon, because the directory is what should be expected on windows OS.

The solution is to modify make script inside Makefile at the kernel Goldfish’s root directory for check-symlink function by removing the exit 1 command and turning the error into a warning. The second step is to modify the output destination that lacks the windows path separator by adding ./ character into the start of the created file inside Kbuild’s cmd_offsets command of writing the asm-offsets.h.

Re-run the make file script and after some long series of kernel compilation process, I arrived at:


Searching through the net for solution of unknown CPU architecture error again proves to be futile. I wonder where are those android developers are going regarding this issue. Seems that nobody in all of android developer community cares about this crucial thing.

Since there is almost no hope to find solution from the crowd source, I decided to investigate this issue further by myself. First thing first, is to isolate the problem, so I don’t have to repeat the lengthy process of make and also for faster problem solution.

So, here is the issue:


The toolchain’s LD utility tries to creates the vmlinux image from several object files, one of which is piggy.o. This object is derived from piggy.S and piggy.gz. piggy.gz is actually a compressed form of arch/arm/boot/Image, where as piggy.S contains source for locating the compressed image using input_data and input_data_end label.

If I combine head.o and misc.o, I also receives unknown CPU architecture as follows:


The error message is the same with combined head.o and piggy.o. Seems that combining any other object file with either piggy.o and head.o will break the linker. To prove it, I perform some test case, by bringing in more object files, let’s call it myTesting1.o and myTesting2.o that can be successfully linked as follows:


There are no error which indicates linking is a success. This also verify that both myTesting1.o and myTesting2.o is a valid object files.

So let’s combined it with misc.o with myTesting1.o:


Well, still no error. So what about combining head.o with myTesting1.o:


Since we already know that myTesting1.o is a valid object file, the above error message from linker that points the error at myTesting1.o is misleading, and the actual problem is the object file that is combined with myTesting1.o, which should be head.o.

Same error by combining piggy.o with myTesting1.o.

What differentiates between those two renegades with the other object files ? Here’s a dump of readelf utility for head.o:


And the dump of misc.o:


After performing detailed examination of compilation script for head.o and piggy.o, the cause of differences in Tag_CPU_arch names on those objects is caused by presence of -march=all switch. Apparently the linker refuse to accept that Tag_CPU_arch should be all for the kernel image.

So, the head.o and piggy.o should be compiled manually by removing the troubling switch, and one last step should be done manually:


To use the zImage for the emulator, copy the image to C:\Android\sdk\system-images\android-19\armeabi-v7a, backup the existing kernel-qemu file and rename the zImage to kernel-qemu.

Here is the kernel in action:



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: