Android x86?

1553 views
Skip to first unread message

David Simmons

unread,
Oct 21, 2008, 12:44:42 PM10/21/08
to android-porting
Has anyone looked into what it would take to port Android to x86? I'm
interested in taking a crack at porting Android to an x86-based
embedded platform I work with. I'm going to download the source later
today and have a look. My main concern is that Dalvik may be tied to
special ARM optimizations...

David

Srinath T V

unread,
Oct 21, 2008, 4:41:59 PM10/21/08
to android-porting
By porting to X86, do you mean running on smart devices like PDA and
others?

I was also looking at porting into some special hardware and add
specific applications on top of it. I assume that android does a
pretty good job of doing power management and would like to see how it
performs compared to other special OS.

Srinath

Zach Hobbs

unread,
Oct 21, 2008, 5:10:35 PM10/21/08
to android...@googlegroups.com
I'd like to port it to x86 to have the dalvik virtual machine running directly
on my linux PC instead of having it run in qemu emulating the ARM arch.

Any idea where to get started with this? Obviously it's ok if most (all) of
the telephony features don't work...

--

Zach Hobbs
HelloAndroid.com
Android OS news, tutorials, downloads

Jay Freeman (saurik)

unread,
Oct 21, 2008, 5:17:59 PM10/21/08
to android...@googlegroups.com
I believe the magic step two between "step one: download code" and "step
three: profit" is just "build code". It seems to already be ported quite
well to x86, and even has user-space reimplementations of kernel extensions
like ashmem ready to go. -J

--------------------------------------------------
From: "Zach Hobbs" <ho...@helloandroid.com>
Sent: Tuesday, October 21, 2008 2:10 PM
To: <android...@googlegroups.com>
Subject: [android-porting] Re: Android x86?

Brian Swetland

unread,
Oct 21, 2008, 8:22:41 PM10/21/08
to android...@googlegroups.com
["Jay Freeman (saurik)" <sau...@saurik.com>]

>
> I believe the magic step two between "step one: download code" and "step
> three: profit" is just "build code". It seems to already be ported quite
> well to x86, and even has user-space reimplementations of kernel extensions
> like ashmem ready to go. -J

Be aware that the SIMULATOR target (where the system sorta builds a
single big linux app) is deprecated and has a lot of problems.

That said, it should be possible to get things running on x86. We've
had somebody in-house tinkering with an x86 native port but he's on
vacation this week, so I'm not sure what the state of that is.

Brian

Jay Freeman (saurik)

unread,
Oct 21, 2008, 8:35:50 PM10/21/08
to android...@googlegroups.com
Fair enough. I got a lot of Dalvik compiling on x86 before starting on it
with my iPhone toolchain, and it at least /seemed/ complete ;P. I didn't
actually bother getting it to a runnable state or I might have noticed that
it actually wasn't. (I'm on 64-bit Debian and I didn't want to spend the
time installing 32-bit libcrypto so I could finish my -m32 build of it all.)

I had completely bypassed the build environment (I usually do so on my first
pass through so I can better isolate build environment challenges from code
challenges and also get a feel for how the codebase is organized). If it, in
fact, isn't already setup for this then other people may find that useful to
dig into things faster, so here is that script. I believe the only thing
between this and linking is having the native libcore parts compiled in
(which had enough random dependencies that I figured I'd bail before I ran
into 32-bit compatibility hell ;P, example: libcrypto).

-J

#!/bin/bash
set -e

libdex=(dalvik/libdex/*.c)
liblog=(system/core/liblog/logd_write.c)
libcutils=(system/core/libcutils/{ashmem-host,atomic,dlmalloc_stubs,mspace}.c)
bionic=(bionic/libc/bionic/dlmalloc.c)
vm=(dalvik/vm/{.,alloc,analysis,arch/generic,interp,jdwp,mterp,oo,reflect,test}/*.c)
vm[${#vm[@]}]=dalvik/vm/mterp/out/InterpC-desktop.c
libnativehelper=(dalvik/libnativehelper/*.c)
libcore=($(find dalvik/libcore -name '*.c'))

include=(-Idalvik -Iframeworks/base/include -Isystem/core/include -Iexternal/safe-iop/include
-Idalvik/libnativehelper/include/nativehelper -Idalvik/vm -Iexternal/icu4c/common
-Iexternal/icu4c/i18n)

define[${#define[@]}]=-include
gcc='gcc -m32'
define[${#define[@]}]=system/core/include/arch/linux-x86/AndroidConfig.h
define[${#define[@]}]=dalvik/vm/mterp/out/InterpAsm-desktop.S

${gcc} -o dalvikvm dalvik/dalvikvm/*.c "${libcutils[@]}"
"${libnativehelper[@]}" "${bionic[@]}" "${libdex[@]}" "${vm[@]}"
"${liblog[@]}" "${include[@]}" "${define[@]}" -lm -pthread -ldl -lz -lffi
${gcc} -o dexdump dalvik/dexdump/*.c "${liblog[@]}" "${libdex[@]}"
"${include[@]}" "${define[@]}" -lz

-J

--------------------------------------------------
From: "Brian Swetland" <swet...@google.com>
Sent: Tuesday, October 21, 2008 5:22 PM


To: <android...@googlegroups.com>
Subject: [android-porting] Re: Android x86?

>

Joe Onorato

unread,
Oct 21, 2008, 8:39:48 PM10/21/08
to android...@googlegroups.com
The x86 port is on a different branch that we haven't released yet, that has a bunch of other experimental and future work.  What's out there right now is pretty close to what's on the G1.  

We'll have that out soon hopefully, but I don't know about the time frame for sure.  We'll probably let what's out there settle down before we try to do that integration.  It'll be a fair bit of work to get that branch synced up with what we released.

-joe

fadden

unread,
Oct 23, 2008, 12:06:30 PM10/23/08
to android-porting
On Oct 21, 5:35 pm, "Jay Freeman \(saurik\)" <sau...@saurik.com>
wrote:
> Fair enough. I got a lot of Dalvik compiling on x86 before starting on it
> with my iPhone toolchain, and it at least /seemed/ complete ;P. I didn't
> actually bother getting it to a runnable state or I might have noticed that
> it actually wasn't. (I'm on 64-bit Debian and I didn't want to spend the
> time installing 32-bit libcrypto so I could finish my -m32 build of it all.)

The only part of Dalvik that isn't portable is the JNI call bridge
(see dalvik/vm/arch directory). We currently use libffi for that on
non-ARM platforms, which is a bit of a performance drag, but on most
non-ARM platforms you don't care as much. :-) I can confirm that it
runs well on x86, and once upon a time we had it running on PPC (which
is mostly interesting because it's big-endian).

The VM runtime has very few external dependencies. The core libraries
have a bit more reach. :-)

kapare

unread,
Oct 23, 2008, 12:52:13 PM10/23/08
to android-porting
Nice

Can you give me clue or example of how to compile the dalvik for x86
or PPC.

simple command line

thx

fadden

unread,
Oct 23, 2008, 7:26:42 PM10/23/08
to android-porting
On Oct 23, 9:52 am, kapare <kevyn.alexandre.p...@gmail.com> wrote:
> Can you give me clue or example of how to compile the dalvik for x86
> or PPC.

Start with:

. build/envsetup.sh
lunch 2

This configures you to build for the desktop, linking against glibc.
This mode is NOT recommended for anything but experimental use. It
may go away. Don't use it; forget you saw it. Thanks.

Build the world:

make

When that completes, you have a working dalvikm on your desktop
machine:

% dalvikvm
E/dalvikvm(19521): ERROR: must specify non-'.' bootclasspath
W/dalvikvm(19521): JNI_CreateJavaVM failed
Dalvik VM init failed (check log file)

To actually do something, you need to specify the bootstrap class path
and give it a place to put DEX data that it uncompresses from jar
files. You can do that with a script like this:

----- snip & save -----
#!/bin/sh

# base directory, at top of source tree; replace with absolute path
base=`pwd`

# configure root dir of interesting stuff
root=$base/out/debug/host/linux-x86/product/sim/system
export ANDROID_ROOT=$root

# configure bootclasspath
bootpath=$root/framework
export BOOTCLASSPATH=$bootpath/core.jar:$bootpath/ext.jar:$bootpath/
framework.jar:$bootpath/android.policy.jar:$bootpath/services.jar

# this is where we create the dalvik-cache directory; make sure it
exists
export ANDROID_DATA=/tmp/dalvik_$USER
mkdir -p $ANDROID_DATA/dalvik_cache

exec dalvikvm $@
-----

Of course, you can't just run this against javac output, since it's
not a Java VM. You have to run your class files through "dx":

% cat > Foo.java
class Foo { public static void main(String[] args) {
System.out.println("Hello, world");
} }
(ctrl-D)
% javac Foo.java
% dx --dex --output=foo.jar Foo.class
% ./rund -cp foo.jar Foo
Hello, world
I/dalvikvm(19564): DestroyJavaVM shutting VM down

(I really ought to get rid of that DestroyJavaVM line -- it's supposed
to be in the log file, but on the desktop the "log file" is stderr.)

Get some info about valid arguments like this:

% ./rund -help

This also shows what options the VM was configured with. The "lunch
2" build has all sorts of additional assertions and checks enabled,
which slows the VM down, but since this is just for experiments it
doesn't matter.

All of the above applies to x86 Linux. Anything else will likely
require a porting effort.

Filipe Abrantes

unread,
Oct 29, 2008, 11:55:23 AM10/29/08
to android-porting
Sorry for the basic question, but what is the lunch command, I've
looked for it in the android tree and google it but was unable to find
any meaningful reference.

Thanks,
Filipe
> All of the above applies tox86Linux.  Anything else will likely
> require a porting effort.

Filipe Abrantes

unread,
Oct 29, 2008, 11:59:59 AM10/29/08
to android-porting
Sorry, I just realised "lunch 2" are the arguments of the envsetup
script :~, nice :P

Cheers,
Filipe


On Oct 23, 11:26 pm, fadden <thefad...@gmail.com> wrote:
> All of the above applies tox86Linux.  Anything else will likely
> require a porting effort.

Jim Ancona

unread,
Oct 29, 2008, 9:28:44 PM10/29/08
to android-porting


On Oct 23, 7:26 pm, fadden <thefad...@gmail.com> wrote:
> On Oct 23, 9:52 am, kapare <kevyn.alexandre.p...@gmail.com> wrote:
>
> > Can you give me clue or example of how to compile the dalvik for x86
> > or PPC.
>
> Start with:
>
>   .build/envsetup.sh
>   lunch 2
>
> This configures you tobuildfor the desktop, linking against glibc.
> This mode is NOT recommended for anything but experimental use.  It
> may go away.  Don't use it; forget you saw it.  Thanks.
>
> Buildthe world:
>
>   make

When I try this (on Ubuntu 8.04, 32 bit), I get a bunch of errors
similar to this:

out/debug/host/linux-x86/product/sim/obj/SHARED_LIBRARIES/
libmedia_intermediates/mediametadataretriever.o:/media/disk/jim/
projects/mydroid/external/skia/include/corecg/SkMath.h:180: more
undefined references to `Android_SkDebugf(char const*, int, char
const*, char const*, ...)' follow
collect2: ld returned 1 exit status
make: *** [out/debug/host/linux-x86/product/sim/obj/SHARED_LIBRARIES/
libmedia_intermediates/LINKED/libmedia.so] Error 1

I can fix them by adding

LOCAL_SHARED_LIBRARIES += libcorecg

to the relevant Android.mk files, but I'm curious if anyone else is
seeing this, or if this is a problem with my environment.

Thanks,

Jim

freedom

unread,
Oct 30, 2008, 2:54:53 AM10/30/08
to android-porting

I ran into similar problem, too. And yes, something similar to
LOCAL_SHARED_LIBRARIES += libcorecg
can solve it.

linp...@gmail.com

unread,
Oct 30, 2008, 5:24:20 AM10/30/08
to android-porting
I have complied the source code for x86 platform,and it seems that it
comlied successfully,but has problems in link libz.so.
the result shows as follow:
============================================
TARGET_PRODUCT=generic
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
========================================================================================
TARGET_PRODUCT=generic
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
target SharedLib: libz (out/host/linux-x86/product/generic/obj/
SHARED_LIBRARIES/libz_intermediates/LINKED/libz.so)
make: *** No rule to make target `build/core/prelink-linux-x86.map',
needed by `out/host/linux-x86/product/generic/symbols/system/lib/
libz.so'. Stop.target SharedLib: libz (out/host/linux-x86/product/
generic/obj/SHARED_LIBRARIES/libz_intermediates/LINKED/libz.so)
make: *** No rule to make target `build/core/prelink-linux-x86.map',
needed by `out/host/linux-x86/product/generic/symbols/system/lib/
libz.so'. Stop.




there is not "prelink-linux-x86.map" in "build/core/" actually but
just the "prelink-linux-x86.arm". Is the "prelink-linux-x86.map
"created automatically?
so any ideas?




Filipe Abrantes

unread,
Oct 30, 2008, 6:37:59 AM10/30/08
to android...@googlegroups.com
same here...

Cheers,
Filipe

dannie

unread,
Oct 30, 2008, 7:11:35 AM10/30/08
to android-porting
Got the same errors with LOCAL_SHARED_LIBRARIES,
fixed them and it seems all was compiled/linked successfully.

Ubuntu 8.04

============================================
TARGET_PRODUCT=sim
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=debug

dannie

unread,
Oct 30, 2008, 7:28:53 AM10/30/08
to android-porting
I'm getting the following error when trying to run dalvik:

~/temp/and$ ./rund -cp foo.jar Foo
E/dalvikvm( 313): Can't open dex cache '/tmp/dalvik_dannie/dalvik-
cache/home@dannie@temp@and@system@framework@core...@classes.dex': No
such file or directory
I/dalvikvm( 313): Unable to open or create cache for /home/dannie/
temp/and/system/framework/core.jar
W/dalvikvm( 313): JNI_CreateJavaVM failed
Dalvik VM init failed (check log file)

But... why? =)

Filipe Abrantes

unread,
Oct 30, 2008, 9:11:10 AM10/30/08
to android-porting
Hi, its a small typo on the rund script, just replace

mkdir -p $ANDROID_DATA/dalvik_cache

with

mkdir -p $ANDROID_DATA/dalvik-cache

and it will (hopefully :P) run

Cheers,
Filipe



On Oct 30, 11:28 am, dannie <dannie....@gmail.com> wrote:
> I'm getting the following error when trying to run dalvik:
>
> ~/temp/and$ ./rund -cp foo.jar Foo
> E/dalvikvm(  313): Can't open dex cache '/tmp/dalvik_dannie/dalvik-
> cache/home@dannie@temp@and@system@framew...@core.jar@classes.dex': No

dannie

unread,
Oct 30, 2008, 9:25:41 AM10/30/08
to android-porting
What's a weird mistake! =)

./rund -cp foo.jar Foo
Hello, world
I/dalvikvm(26218): DestroyJavaVM shutting VM down

So... It's working.

freedom

unread,
Oct 30, 2008, 9:53:15 AM10/30/08
to android-porting

a quick fix to the problem is "choosetype release" after
"lunch 2" because in release mode "SkDebugf()" is an
empty function instead of "Android_SkDebugf()"

On Oct 30, 9:28 am, Jim Ancona <j...@anconafamily.com> wrote:

Filipe Abrantes

unread,
Nov 5, 2008, 9:34:16 AM11/5/08
to android-porting
Hi all,

The target simulator compilation method for x86 works and we are able
to run dalvik. However I am trying to compile android with all its
components natively for x86. To do so I set up the repo thing as
usually and then run make (without any "lunch") as

make TARGET_ARCH=x86

it goes through quite a few modules but eventually it complains about
the lack of rule to make emulator. I dig through a few files in build/
(core and others) to try to understand how I could change this but I
was not successfull. The output error is:

Install: out/host/linux-x86/bin/dexlist
host Prebuilt: dexpreopt (out/host/linux-x86/obj/EXECUTABLES/
dexpreopt_intermediates/dexpreopt.py)
make: *** No rule to make target `out/host/linux-x86/bin/emulator',
needed by `out/host/linux-x86/bin/dexpreopt.py'. Stop.

Any help is much appreciated, Cheers,
Filipe

freedom

unread,
Nov 7, 2008, 4:22:41 AM11/7/08
to android-porting

Try
make TARGET_ARCH=x86 TARGET_BUILD_TYPE=release TARGET_PRODUCT=sim

Filipe Abrantes

unread,
Nov 7, 2008, 6:32:56 AM11/7/08
to android-porting
Ok, but that will compile for the target 'SIMULATOR' right? My idea
was compile everything for an x86 device. I don't fully understand the
differences between the simulator target and the other ones... for
instance I understand that on the simulator target dalvik is compiled
against the 'standard' glibc but what else is different?

Cheers,
Filipe

Brian Swetland

unread,
Nov 7, 2008, 6:36:40 AM11/7/08
to android...@googlegroups.com
[Filipe Abrantes <filipe....@gmail.com>]
>
> Ok, but that will compile for the target 'SIMULATOR' right? My idea
> was compile everything for an x86 device. I don't fully understand the
> differences between the simulator target and the other ones... for
> instance I understand that on the simulator target dalvik is compiled
> against the 'standard' glibc but what else is different?

The SIMULATOR target tries to build the entire system more like an
application. Things don't really run in multiple processes. A lot of
things don't work the way they would on a real devices. It still exists
as a debugging aid (you can run it all under valgrind which is kinda
handy at times) but it's deprecated and will be going away (as soon as
we get valgrind type functionality with the emulator or on-device). It
is the source of a lot of cruft in the build.

Filipe Abrantes

unread,
Nov 7, 2008, 6:53:18 AM11/7/08
to android...@googlegroups.com
Thanks for the clarification Brian. The big app you mention is the
'dalvikvm' binary? Could you point us how we could get, for instance,
the android home app running with this dalvikvm binary? Is it even
possible to do this... I mean we were able to run a simple hello world
java app, but I could not get any of the Android jars (e.g.
out/target/common/obj/APPS/Home_intermediaries/classes.jar) running.

Cheers,
Filipe


Could you help us understand what is required to get, for instance, the
home app running on

DYChen

unread,
Nov 7, 2008, 9:40:07 PM11/7/08
to android-porting
Brian,

You mentioned on Oct 21 that Google has done some native x86 port of
Android. Do you know when the code related to the native x86 port will
be released to the Android Open Source Project? We are interested in
getting Android to run on various x86-based devices and are willing to
contiribute toward the native x86 port effort. But it will be better
to base it on top of the native x86 port that Google has done.

Thanks,
Dong-Yuan

Brian Swetland

unread,
Nov 7, 2008, 9:42:32 PM11/7/08
to android...@googlegroups.com
[DYChen <dong-yu...@intel.com>]

The engineer responsible for this project has been out of the office for
a couple weeks and is travelling this week. He's working with our team
to get his patches into the open source tree, but I think we're still a
couple weeks away from completion there. We know people are excited
about building android for x86 targets and will try to get this code
cleaned up and submitted soon.

Brian

DYChen

unread,
Nov 9, 2008, 4:01:45 AM11/9/08
to android-porting


On Nov 7, 6:42 pm, Brian Swetland <swetl...@google.com> wrote:
>
> The engineer responsible for this project has been out of the office for
> a couple weeks and is travelling this week.  He's working with our team
> to get his patches into the open source tree, but I think we're still a
> couple weeks away from completion there.  We know people are excited
> about building android for x86 targets and will try to get this code
> cleaned up and submitted soon.

Brian,

Thanks for the update. I look forward to the release of x86 patches
that will enable us to run Android natively on x86 devices or PC.

Do you know how the project repositories will be structured to
accommodate the support of various x86 devices or targets? Are we
going to see different branches for x86 port? Are we expect to see
macros (such as #ifdef X86) guarding x86 related code in the source?
I'm looking for some guidelines on how x86 related code should be
integrated with the existing Android source. I haven't seen any
guideline regarding coding style or repository structures for hosting
device or architecture specific code yet. Maybe I haven't looked hard
enough. Any pointer is greatly appreciated.

Thanks,
Dong-Yuan

David Turner

unread,
Nov 11, 2008, 4:28:27 AM11/11/08
to android...@googlegroups.com
Just to make it clear, the x86 Android port, at that point, requires running an Android kernel on a x86 device with flash storage.
This is very different from running Dalvik under Windows or a pre-existing Linux installation (though with time these things
will be possible to)

Gergely Kis

unread,
Nov 13, 2008, 3:39:28 AM11/13/08
to android...@googlegroups.com
Hello,

Why is flash storage necessary? We were able to run Android over NFS,
and others have used ext2 or ext3. So there should be no direct
requirement for using a flash device specific filesystem like yaffs.
As far as I know the only specific requirement is that read-write mmap
has to be possible.

Are there other dependencies on flash storage?

Best Regards,
Gergely

On Tue, Nov 11, 2008 at 10:28 AM, David Turner <di...@android.com> wrote:
> Just to make it clear, the x86 Android port, at that point, requires running
> an Android kernel on a x86 device with flash storage.
> This is very different from running Dalvik under Windows or a pre-existing
> Linux installation (though with time these things
> will be possible to)
>
> On Sun, Nov 9, 2008 at 10:01 AM, DYChen <dong-yu...@intel.com> wrote:

[...]

David Turner

unread,
Nov 13, 2008, 2:28:38 PM11/13/08
to android...@googlegroups.com
I just mean that it's the only option that has really been tested in real life :-)

markgross

unread,
Nov 13, 2008, 8:04:36 PM11/13/08
to android-porting
We have been looking into this and we are in the process of internal
legal review and will be starting an AndroidOnIA project within the
context of the Android open source project soon.

We have a few interesting targets we are working on, but initially we
hope to get a KVM (or your VTx enabled VMM of choice) guest image
build working for people to play with,and then start pushing out
targets for real hardware.

--mgross

On Oct 21, 8:44 am, David Simmons <simm...@davidsimmons.com> wrote:
> Has anyone looked into what it would take to port Android to x86? I'm
> interested in taking a crack at porting Android to an x86-based
> embedded platform I work with. I'm going to download the source later
> today and have a look. My main concern is that Dalvik may be tied to
> special ARM optimizations...
>
> David

Gang lee

unread,
Nov 13, 2008, 8:52:01 PM11/13/08
to android-porting
Hi all:

Although I can compile with the command line:
make -j2 TARGET_ARCH=x86 TARGET_PRODUCT=generic
TARGET_SIMULATOR=true TARGET_BUILD_TYPE=release TARGET_OS=linux
LOCAL_PRELINK_MODULE=false

but I found lot of modules cannot be compiled with
"TARGET_SIMULATOR=true", if set false,the bionic(libc) met some files
(.h files) missing and compile failed.
Has anyone compiled the bionic successful?

Another question, Does any one knows more detail information about the
official x86 porting? for example:
Does the x86 porting support OpenGL?
Does the x86 porting still use openCore as the Media Framework? and
the openCore can be replaced by others(just like Hilex or GStreamer)?

David Turner

unread,
Nov 14, 2008, 6:24:08 AM11/14/08
to android...@googlegroups.com
Do not use TARGET_SIMULATOR=true, this flag should only be set when building the Android simulator,
which doesn't require all system libraries and runs the Android "system" into a single process on the host
machine.

that's why you have problems when building certain libraries (e.g. the simulator uses the host's C library, not Bionic)

the x86 port only uses Android's own software OpenGL renderer. There is no support for hardware-accelerated graphics
yet (and it's not like there is any kind of standard API for that on Linux). OpenCore is supposed to be portable, so I
assume it runs (but I may be mistaken)

you can't easily replace OpenCore with something else, unless you modify all the framework code that depends on it.
(this has never been tested internally)

Gang lee

unread,
Nov 16, 2008, 9:05:19 PM11/16/08
to android-porting
Hi David,

Think you for your answer.

I'm sorry for my copy&paste mistake.
I can compile with TARGET_SIMULATOR=true without any problem.
but when set "TARGET_SIMULATOR=false" in compile command, error below
happend
make: *** No rule to make target `out/host/linux-x86/bin/emulator',
needed by `out/host/linux-x86/bin/dexpreopt.py'. Stop.

Then I want to compile the bionic first.I did as follow.
1. Modify the Android.mk in mydroid/bionic to compile bionic in
simulator target
2. Compile all again with TARGET_SIMULATOR=true
the output as follow:
-------------------output------------------------
target thumb C: linker <= bionic/linker/linker.c
target thumb C: linker <= bionic/linker/dlfcn.c
bionic/linker/linker.c:15:25: error: sys/atomics.h: No such file or
directory
bionic/linker/linker.c:16:21: error: sys/tls.h: No such file or
directory
In file included from bionic/linker/dlfcn.c:18:
bionic/linker/linker.h:20: error: expected specifier-qualifier-list
before 'uintptr_t'
In file included from bionic/linker/linker.c:18:
bionic/linker/linker.h:20: error: expected specifier-qualifier-list
before 'uintptr_t'
bionic/linker/linker.h:50: error: expected specifier-qualifier-list
before 'uintptr_t'
bionic/linker/linker.h:50: error: expected specifier-qualifier-list
before 'uintptr_t'
---------------copy end(firest several lines)------------------

How can I compile bionic and other modules(init etc.)??

On 11月14日, 下午7时24分, "David Turner" <di...@android.com> wrote:
> Do not use TARGET_SIMULATOR=true, this flag should only be set when building
> the Android simulator,
> which doesn't require all system libraries and runs the Android "system"
> into a single process on the host
> machine.
>
> that's why you have problems when building certain libraries (e.g. the
> simulator uses the host's C library, not Bionic)
>
> the x86 port only uses Android's own software OpenGL renderer. There is no
> support for hardware-accelerated graphics
> yet (and it's not like there is any kind of standard API for that on Linux).
> OpenCore is supposed to be portable, so I
> assume it runs (but I may be mistaken)
>
> you can't easily replace OpenCore with something else, unless you modify all
> the framework code that depends on it.
> (this has never been tested internally)
>

Gang lee

unread,
Nov 16, 2008, 9:27:56 PM11/16/08
to android-porting
Hi David

A few additional information.

when I compiled whit TARGET_SIMULATOR=false, the output said "find:
prebuilt/android-x86: No such file or directory"
the make try to find prebuilt/android-x86 directory, and there is no
such directory,only have linux-x86 directory.
In the mydroid/build/core/envsetup.mk
--------------------------------
envsetup.mk-----------------------------
ifeq ($(TARGET_SIMULATOR),true)
TARGET_PREBUILT_TAG := $(TARGET_OS)-$(TARGET_ARCH)
else
TARGET_PREBUILT_TAG := android-$(TARGET_ARCH)
endif
--------------------------------copy end-----------------------------
Say in other words,If I set TARGET_SIMULATOR=false, I cannot use the
prebuild content??


On 11月14日, 下午7时24分, "David Turner" <di...@android.com> wrote:
> Do not use TARGET_SIMULATOR=true, this flag should only be set when building
> the Android simulator,
> which doesn't require all system libraries and runs the Android "system"
> into a single process on the host
> machine.
>
> that's why you have problems when building certain libraries (e.g. the
> simulator uses the host's C library, not Bionic)
>
> the x86 port only uses Android's own software OpenGL renderer. There is no
> support for hardware-accelerated graphics
> yet (and it's not like there is any kind of standard API for that on Linux).
> OpenCore is supposed to be portable, so I
> assume it runs (but I may be mistaken)
>
> you can't easily replace OpenCore with something else, unless you modify all
> the framework code that depends on it.
> (this has never been tested internally)
>

Filipe Abrantes

unread,
Nov 19, 2008, 7:28:34 PM11/19/08
to android...@googlegroups.com
This would be very interesting. Any word on timing?

Cheers,
Filipe

neo

unread,
Dec 1, 2008, 1:12:22 AM12/1/08
to android-porting
Good afternoon everyone,
there is a problem during my Android kernel compiling .
I followed the guideline which is
https://sites.google.com/a/android.com/opensource/download
and searched google for the answer, but still it cannot be solved.

===
Cannot locate File/ Basename.pm in @INC
( @INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/
share
/perl/5.8.8 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/
5.8 /usr/local
/lib/site_perl. )
at external/webkit/JavaScriptCore/pcre/dftables line 47

BEGIN failed--compilation aborted at external/webkit/JavaScriptCore/
pcre/dftables line 47

make" ***[out/target/product/generic/obj/STATIC_LIBRARIES/
libkjs_intermediates/chartables.c]Error2
===
Can anyone give me some advice? I'll appreciate u very much.

thanks for reading

Lucky-dog

unread,
Dec 1, 2008, 8:30:56 AM12/1/08
to android-porting
My ubuntu is 8.10. I try the tips to compile android for x86. But it
seem envsetup.sh does not work. Would you like to help me? Thank you
very much. The log is as below.
thomast@ubuntu:~/mydroid/build$ echo $SHELL
/bin/bash
thomast@ubuntu:~/mydroid/build$ bash --version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
thomast@ubuntu:~/mydroid/build$ ./envsetup.sh lunch 2
thomast@ubuntu:~/mydroid/build$ ./envsetup.sh help
thomast@ubuntu:~/mydroid/build$



On Oct 24, 7:26 am, fadden <thefad...@gmail.com> wrote:
> On Oct 23, 9:52 am, kapare <kevyn.alexandre.p...@gmail.com> wrote:
>
> > Can you give me clue or example of how to compile the dalvik for x86
> > or PPC.
>
> Start with:
>
>   . build/envsetup.sh
>   lunch 2
>
> This configures you to build for the desktop, linking against glibc.
> This mode is NOT recommended for anything but experimental use.  It
> may go away.  Don't use it; forget you saw it.  Thanks.
>
> Build the world:
>
>   make
>
> When that completes, you have a working dalvikm on your desktop
> machine:
>
> % dalvikvm
> E/dalvikvm(19521): ERROR: must specify non-'.' bootclasspath
> W/dalvikvm(19521): JNI_CreateJavaVM failed
> Dalvik VM init failed (check log file)
>
>   % ./rund -cp foo.jar Foo
>   Hello, world

Urs Grob

unread,
Dec 1, 2008, 8:38:07 AM12/1/08
to android...@googlegroups.com
$ . build/envsetup.sh
$ lunch 2

are two separate commands. The first one sets up the environment and
the second one sets which configuration you want to build.

Lucky-dog

unread,
Dec 3, 2008, 9:12:57 AM12/3/08
to android-porting
hi all
when i try to compile the source on DEBUG x86. A error is reported
out as below. Would you like to let me know how to fix it? Thank you
very much.
thomast@ubuntu:~/mydroid$ make
build/core/product_config.mk:229: WARNING: adding test OTA key
build/core/main.mk:177: implicitly installing apns-conf_sdk.xml
============================================
TARGET_PRODUCT=sim
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=debug
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
target thumb C++: libkjs <= external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp
In file included from /usr/include/c++/4.3/bits/stl_pair.h:65,
from /usr/include/c++/4.3/utility:68,
from external/webkit/JavaScriptCore/wtf/
VectorTraits.h:27,
from external/webkit/JavaScriptCore/kjs/
LocalStorage.h:29,
from external/webkit/JavaScriptCore/kjs/
JSVariableObject.h:32,
from external/webkit/JavaScriptCore/kjs/
JSGlobalObject.h:26,
from external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp:32:
/usr/include/c++/4.3/bits/stl_move.h:80: error: redefinition of
‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
external/webkit/JavaScriptCore/../WebCore/platform/android/stl/
algorithm:65: error: ‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
previously declared here
make: *** [out/debug/host/linux-x86/product/sim/obj/STATIC_LIBRARIES/
libkjs_intermediates/bindings/NP_jsobject.o] Error 1
thomast@ubuntu:~/mydroid$

thomast@ubuntu:~/mydroid$ make
build/core/product_config.mk:229: WARNING: adding test OTA key
build/core/main.mk:177: implicitly installing apns-conf_sdk.xml
============================================
TARGET_PRODUCT=sim
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=debug
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
target thumb C++: libkjs <= external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp
In file included from /usr/include/c++/4.3/bits/stl_pair.h:65,
from /usr/include/c++/4.3/utility:68,
from external/webkit/JavaScriptCore/wtf/
VectorTraits.h:27,
from external/webkit/JavaScriptCore/kjs/
LocalStorage.h:29,
from external/webkit/JavaScriptCore/kjs/
JSVariableObject.h:32,
from external/webkit/JavaScriptCore/kjs/
JSGlobalObject.h:26,
from external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp:32:
/usr/include/c++/4.3/bits/stl_move.h:80: error: redefinition of
‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
external/webkit/JavaScriptCore/../WebCore/platform/android/stl/
algorithm:65: error: ‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
previously declared here
make: *** [out/debug/host/linux-x86/product/sim/obj/STATIC_LIBRARIES/
libkjs_intermediates/bindings/NP_jsobject.o] Error 1
thomast@ubuntu:~/mydroid$

thomast@ubuntu:~/mydroid$ make
build/core/product_config.mk:229: WARNING: adding test OTA key
build/core/main.mk:177: implicitly installing apns-conf_sdk.xml
============================================
TARGET_PRODUCT=sim
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=debug
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
target thumb C++: libkjs <= external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp
In file included from /usr/include/c++/4.3/bits/stl_pair.h:65,
from /usr/include/c++/4.3/utility:68,
from external/webkit/JavaScriptCore/wtf/
VectorTraits.h:27,
from external/webkit/JavaScriptCore/kjs/
LocalStorage.h:29,
from external/webkit/JavaScriptCore/kjs/
JSVariableObject.h:32,
from external/webkit/JavaScriptCore/kjs/
JSGlobalObject.h:26,
from external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp:32:
/usr/include/c++/4.3/bits/stl_move.h:80: error: redefinition of
‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
external/webkit/JavaScriptCore/../WebCore/platform/android/stl/
algorithm:65: error: ‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
previously declared here
make: *** [out/debug/host/linux-x86/product/sim/obj/STATIC_LIBRARIES/
libkjs_intermediates/bindings/NP_jsobject.o] Error 1
thomast@ubuntu:~/mydroid$

thomast@ubuntu:~/mydroid$ make
build/core/product_config.mk:229: WARNING: adding test OTA key
build/core/main.mk:177: implicitly installing apns-conf_sdk.xml
============================================
TARGET_PRODUCT=sim
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=debug
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
target thumb C++: libkjs <= external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp
In file included from /usr/include/c++/4.3/bits/stl_pair.h:65,
from /usr/include/c++/4.3/utility:68,
from external/webkit/JavaScriptCore/wtf/
VectorTraits.h:27,
from external/webkit/JavaScriptCore/kjs/
LocalStorage.h:29,
from external/webkit/JavaScriptCore/kjs/
JSVariableObject.h:32,
from external/webkit/JavaScriptCore/kjs/
JSGlobalObject.h:26,
from external/webkit/JavaScriptCore/bindings/
NP_jsobject.cpp:32:
/usr/include/c++/4.3/bits/stl_move.h:80: error: redefinition of
‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
external/webkit/JavaScriptCore/../WebCore/platform/android/stl/
algorithm:65: error: ‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
previously declared here
make: *** [out/debug/host/linux-x86/product/sim/obj/STATIC_LIBRARIES/
libkjs_intermediates/bindings/NP_jsobject.o] Error 1
thomast@ubuntu:~/mydroid$

Lucky-dog

unread,
Dec 4, 2008, 10:28:11 AM12/4/08
to android-porting
hi all
I fixed it with renaming swap to swapab. But now I have another
question needed your help. I can't let the following command get to be
run.
dx --dex --output=foo.jar Foo.class
What is the dx command and where is it? Would you like to help me
out? Thank you very much.

Lucky-dog

unread,
Dec 5, 2008, 6:49:41 PM12/5/08
to android-porting
I got it. it located in out/host/linux-x86/bin. Thanks.

squix

unread,
Dec 11, 2008, 11:53:19 AM12/11/08
to android-porting
Hi group

Does anyone have an idea why I get this error?
============================================
TARGET_PRODUCT=generic
TARGET_SIMULATOR=
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
host C++: simulator <= development/simulator/app/DeviceManager.cpp
In file included from /usr/include/wx-2.6/wx/memory.h:20,
from /usr/include/wx-2.6/wx/object.h:25,
from /usr/include/wx-2.6/wx/wx.h:16,
from development/simulator/app/DeviceManager.cpp:12:
/usr/include/wx-2.6/wx/string.h:771: error: âwxChar& wxString::operator
[](unsigned int)â cannot be overloaded
/usr/include/wx-2.6/wx/string.h:768: error: with âwxChar&
wxString::operator[](size_t)â
In file included from /usr/include/wx-2.6/wx/stream.h:26,
from /usr/include/wx-2.6/wx/image.h:24,
from /usr/include/wx-2.6/wx/gtk/cursor.h:23,
from /usr/include/wx-2.6/wx/cursor.h:24,
from /usr/include/wx-2.6/wx/event.h:32,
from /usr/include/wx-2.6/wx/wx.h:23,
from development/simulator/app/DeviceManager.cpp:12:
/usr/include/wx-2.6/wx/filefn.h:322: error: zero width for bit-field
âwxAssert_323::BadFileSizeTypeâ
In file included from /usr/include/wx-2.6/wx/utils.h:38,
from /usr/include/wx-2.6/wx/cursor.h:37,
from /usr/include/wx-2.6/wx/event.h:32,
from /usr/include/wx-2.6/wx/wx.h:23,
from development/simulator/app/DeviceManager.cpp:12:
/usr/include/wx-2.6/wx/longlong.h: In constructor
âwxLongLongNative::wxLongLongNative(long int, long unsigned int)â:
/usr/include/wx-2.6/wx/longlong.h:115: warning: left shift count >=
width of type
/usr/include/wx-2.6/wx/longlong.h: In member function âlong int
wxLongLongNative::GetHi() constâ:
pe
/usr/include/wx-2.6/wx/longlong.h: In constructor
âwxULongLongNative::wxULongLongNative(long unsigned int, long unsigned
int)â:
/usr/include/wx-2.6/wx/longlong.h:333: warning: left shift count >=
width of type
/usr/include/wx-2.6/wx/longlong.h: In member function âlong unsigned
int wxULongLongNative::GetHi() constâ:
/usr/include/wx-2.6/wx/longlong.h:351: warning: right shift count >=
width of type
In file included from development/simulator/app/LogWindow.h:13,
from development/simulator/app/MainFrame.h:11,
from development/simulator/app/MyApp.h:12,
from development/simulator/app/DeviceManager.cpp:17:
development/simulator/app/LogPrefsDialog.h: At global scope:
development/simulator/app/LogPrefsDialog.h:28: warning: âtypedefâ was
ignored in this declaration
make: *** [out/host/linux-x86/obj/EXECUTABLES/simulator_intermediates/
DeviceManager.o] Error 1


Is this maybe a x86_64 specific problem? I followed the description
for x86_64 and could do the "normal" build. But if I try to do the x86
"application-like" build I get that error... I'm trying this on a
Ubuntu 8.10 system...

Thanks, for any help

On Dec 6, 12:49 am, Lucky-dog <Honglian...@gmail.com> wrote:
> I got it. it located in out/host/linux-x86/bin. Thanks.
>
> On Dec 4, 10:28 am, Lucky-dog <Honglian...@gmail.com> wrote:
>
> > hi all
> >    I fixed it with renaming swap to swapab. But now I have another
> > question needed your help. I can't let the following command get to be
> > run.
> >    dx --dex --output=foo.jar Foo.class
> >    What is the dx command and where is it?  Would you like to help me
> > out? Thank you very much.
>
> > On Dec 3, 10:12 pm, Lucky-dog <Honglian...@gmail.com> wrote:
>
> > > hi all
> > >    when i try to compile the source on DEBUGx86. A error is reported

Piethein Strengholt

unread,
Dec 18, 2008, 3:10:03 PM12/18/08
to android-porting

Dima Zavin

unread,
Dec 18, 2008, 3:23:17 PM12/18/08
to android...@googlegroups.com
Try this (only tested on EeePC 701):

repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
repo sync
TARGET_ARCH=x86 TARGET_PRODUCT=eee_701 DISABLE_DEXPREOPT=true make -j8 installer_img
dd if=out/target/product/eee_701/installer.img of=/dev/<usbstick of your choice> ; sync

Boot from the usb stick. The installer is a bit crude, and needs polishing and generalizing but it works. Note: It WILL WIPE your EeePC drive. :)

--Dima


On Thu, Dec 18, 2008 at 12:10 PM, Piethein Strengholt <pietheins...@gmail.com> wrote:

Dima Zavin

unread,
Dec 18, 2008, 3:25:32 PM12/18/08
to android...@googlegroups.com
Argh, forgot to mention that you'll need a local_manifest.xml that looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="platform/vendor/asus/eee_701" path="vendor/asus/eee_701"/>
</manifest>

Chris

unread,
Dec 18, 2008, 3:39:29 PM12/18/08
to android-porting
Thanks Dima!

The most exciting update yet comes the day before I leave for a two
week vacation. Hopefully I will be able to try it before I leave. I
have been trying to repo init and repo sync to this since yesterday
but am getting a ton of socket errors. It could be an issue with our
SOCKs proxies but I have tried a number of different proxy servers in
our company (they do not usually all go down at the same time). I am
not sure how many others are having similar problems.

Thanks for the details,
Chris Elford
Intel Software Services Group

Filipe Abrantes

unread,
Dec 18, 2008, 4:47:26 PM12/18/08
to android...@googlegroups.com
Very cool, thanks for the effort! Can't wait to try it...

Cheers
Filipe

freedom

unread,
Dec 19, 2008, 2:04:48 AM12/19/08
to android-porting
after boot from my USB stick, I saw
init: Unable to open persisent property directory /data/property
errno: 2
and
I/installer( 1865): Waiting for device: /dev/block/sdb2
than some USB information, and shell prompt

my internal SSD was not touched at all, that is, it didn't start to
install

On Dec 19, 4:23 am, "Dima Zavin" <d...@android.com> wrote:
> Try this (only tested on EeePC 701):
>
> repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
> repo sync
> TARGET_ARCH=x86 TARGET_PRODUCT=eee_701 DISABLE_DEXPREOPT=true make -j8
> installer_img
> dd if=out/target/product/eee_701/installer.img of=/dev/<usbstick of your
> choice> ; sync
>
> Boot from the usb stick. The installer is a bit crude, and needs polishing
> and generalizing but it works. Note: It WILL WIPE your EeePC drive. :)
>
> --Dima
>
> On Thu, Dec 18, 2008 at 12:10 PM, Piethein Strengholt <
>

Huan Truong

unread,
Dec 19, 2008, 2:26:24 PM12/19/08
to android-porting
I could not compile the cupcake branch as of 1:20PM CST. There seems
to be some error while compiling fst.o

external/srec/tools/thirdparty/OpenFst/fst/lib/../../fst/lib/vector-
fst.h:404: error: ‘memcpy’ was not declared in this scope
external/srec/tools/thirdparty/OpenFst/fst/lib/../../fst/lib/vector-
fst.h: In member function ‘W fst::WeightFromString<W>::operator()
(const std::string&) [with W = fst::LogWeight]’:
external/srec/tools/thirdparty/OpenFst/fst/lib/../../fst/lib/vector-
fst.h:412: error: ‘memcpy’ was not declared in this scope
make: *** [out/host/linux-x86/obj/SHARED_LIBRARIES/
libfst_intermediates/symbol-table.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [out/host/linux-x86/obj/SHARED_LIBRARIES/
libfst_intermediates/fst.o] Error 1


Any suggestions?

On Dec 18, 2:23 pm, "Dima Zavin" <d...@android.com> wrote:
> Try this (only tested on EeePC 701):
>
> repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
> repo sync
> TARGET_ARCH=x86 TARGET_PRODUCT=eee_701 DISABLE_DEXPREOPT=true make -j8
> installer_img
> dd if=out/target/product/eee_701/installer.img of=/dev/<usbstick of your
> choice> ; sync
>
> Boot from the usb stick. The installer is a bit crude, and needs polishing
> and generalizing but it works. Note: It WILL WIPE your EeePC drive. :)
>
> --Dima
>
> On Thu, Dec 18, 2008 at 12:10 PM, Piethein Strengholt <
>

Dima Zavin

unread,
Dec 19, 2008, 3:05:41 PM12/19/08
to android...@googlegroups.com

after boot from my USB stick, I saw
 init: Unable to open persisent property directory /data/property
errno: 2
and

This is harmless in this case.
 
 I/installer( 1865): Waiting for device: /dev/block/sdb2
than some USB information, and shell prompt
 
my internal SSD was not touched at all, that is, it didn't start to
install

As I mentioned, the installer is definitely not robust. It assumes that sda will be the internal SSD, and sdb will be the usbstick (iirc). You might need to hack in the bios to make sure that the devices are assigned properly (in the order that we want them).

The real solution is to pull in volume-id stuff from udev (drop it somewhere into external/, and add it to the build), have init call out to it when a new block device shows up, and have it drop the right device node into /dev/block-by-volid/...

Then the installer can refer to the right volume by volumeid, and can avoid this device name hardcoding mess. When we build the images, we include the appropriate volume id already, I just didn't get a chance to get the init side of things done. Patches are welcome.

Thanks.

--Dima

squix

unread,
Dec 19, 2008, 3:57:24 PM12/19/08
to android-porting
I had the same problem. It has to to with the gcc version your using
and the header refactoring that they did for that version. You can fix
errors like that by simply adding the right includes in the file
complaining.
In 90% I had to add one of these
#include <cstdlib>
#include <cstring>
but there were other cases as well.

After fixing many of these issues I finally could build the installer
image. But when I run it on my very old machine (Geode GX1) only GRUB
is printed and a blinking cursor. What might be here the problem? I
thought besides less important things the eee 701 is just a standard
x86 system, or am I wrong. Is there another product I should build it
for?

Chris

unread,
Dec 19, 2008, 4:44:33 PM12/19/08
to android-porting
I have been able to successfully run the eee701 cupcake build on an
MSI Wind. I have a _VERY_ preliminary script that takes the
installer.img and a USB stick and creates a "live" USB stick that can
be booted. Running off of USB will make some apps timeout a bit more
because its not as fast as internal storage but it makes it easy to
try it out.

If anyone is interested in the liveUSB conversion script, I can submit
a changeset (probably to put in vendor/asus/eee_701 for now). Bear in
mind this version of the script is very preliminary and I plan to
update it some after my vacation.

Thx,

Chris Elford
Intel Software Services Group

Huan Truong

unread,
Dec 19, 2008, 5:05:06 PM12/19/08
to android-porting
Chris et al,

Can you tell me the version of gcc you're using to compile. Seems like
gcc-4.3 has many problems with cupcake.

Chris

unread,
Dec 19, 2008, 5:14:07 PM12/19/08
to android-porting
/usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus

It seems to be using the gcc that I happen to have installed on my
Ubuntu 8.04 system...

celford@celford-ubuntu:~/cupcake$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c+
+,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --
enable-objc-gc --enable-mpfr --enable-targets=all --enable-
checking=release --build=i486-linux-gnu --host=i486-linux-gnu --
target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

Part of the build may also be using the bits at cupcake/prebuilt/linux-
x86/toolchain/i686-unknown-linux-gnu-4.2.1...

Thx,
Chris

Chris

unread,
Dec 19, 2008, 11:00:22 PM12/19/08
to android-porting
Note that cupcake seems to have been integrated into master now.
(See this thread http://groups.google.com/group/repo-discuss/browse_thread/thread/7951d0391b87aad5?pli=1).
Note that it looks like a lot more stuff now builds with the gcc in
prebuilds /home/celford/mydroid/prebuilt/linux-x86/toolchain/i686-
unknown-linux-gnu-4.2.1/bin/ than before when more stuff seemed to be
using the gcc on my system. This could just be the phase of the build
that I checked it at though.

I have been trying to repo upload the script to take the installer.img
file and make a live-usb key as a changeset to vendor/asus/eee_701 but
am still running into some issues that look like kernel.org
configuration errors. I'll check back during my vacation for a
response to that thread and if it is resolved so I can repo upload.
In the meantime, folks have asked for the script now so, I've created
a bugtracker and put the early script there at
http://code.google.com/p/android/issues/detail?id=1598.

basic usage details are documented in the script for now.

Thx,
Chris Elford
Intel Software Services Group

Huan Truong

unread,
Dec 20, 2008, 1:38:54 AM12/20/08
to android-porting
Thanks Chris!

Looks like specifying CC to gcc-4.2 resolves most of the errors while
compiling with gcc-4.3. So just to take a note for those who received
same errors I had.

- Huan T.

Brock

unread,
Dec 20, 2008, 8:45:32 AM12/20/08
to android-porting
Where should the local_manifest.xml file be placed?

On Dec 18, 2:25 pm, "Dima Zavin" <d...@android.com> wrote:
> Argh, forgot to mention that you'll need a local_manifest.xml that looks
> something like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <manifest>
>   <project name="platform/vendor/asus/eee_701" path="vendor/asus/eee_701"/>
> </manifest>
>

Brock

unread,
Dec 20, 2008, 9:17:28 AM12/20/08