El grup a què estàs enviant el missatge és un grup d'Usenet. Els missatges enviats a aquest grup permeten que la teva adreça electrònica sigui visible per qualsevol usuari d'Internet.
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...
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
On Oct 21, 11: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...
> 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
> On Oct 21, 11: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...
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-porting@googlegroups.com> Subject: [android-porting] Re: Android x86?
> 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...
> On Tuesday 21 October 2008 4:41:59 pm Srinath T V wrote: >> 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
>> On Oct 21, 11: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...
> 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.
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).
>> 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.
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.
> > 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.
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. :-)
> 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. :-)
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
# 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.
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
On Oct 23, 11: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 forx86
> > 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:
> 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
> # 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 tox86Linux. Anything else will likely
> require a porting effort.
> 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 forx86
> > 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:
> 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
> # 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 tox86Linux. Anything else will likely
> require a porting effort.
> 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.
> 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.
fadden 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:
> 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
> # 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.
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?
freedom wrote: > I ran into similar problem, too. And yes, something similar to > LOCAL_SHARED_LIBRARIES += libcorecg > can solve it.
> On Oct 30, 9:28 am, Jim Ancona <j...@anconafamily.com> wrote:
>> 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.
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
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? =)
On Oct 30, 2:11 pm, dannie <dannie....@gmail.com> wrote:
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:
> 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.
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
On Oct 30, 1:53 pm, freedom <koansin....@gmail.com> wrote:
> 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:
> > 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:
> 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
> On Oct 30, 1:53 pm, freedom <koansin....@gmail.com> wrote:
> > 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:
> > > 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:
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
On Nov 7, 9:22 am, freedom <koansin....@gmail.com> wrote:
> Try
> make TARGET_ARCH=x86 TARGET_BUILD_TYPE=release TARGET_PRODUCT=sim
> On Nov 5, 10:34 pm, Filipe Abrantes <filipe.abran...@gmail.com> wrote:
> > 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
> > On Oct 30, 1:53 pm, freedom <koansin....@gmail.com> wrote:
> > > 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:
> > > > 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:
> 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.
> On Nov 7, 9:22 am, freedom <koansin....@gmail.com> wrote:
> > Try
> > make TARGET_ARCH=x86 TARGET_BUILD_TYPE=release TARGET_PRODUCT=sim
> > On Nov 5, 10:34 pm, Filipe Abrantes <filipe.abran...@gmail.com> wrote:
> > > 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
> > > On Oct 30, 1:53 pm, freedom <koansin....@gmail.com> wrote:
> > > > 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:
> > > > > 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.
> > > > > > 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:
|
