yes, I have run it. 10482 has 2 issues, my 2nd item fixed one issue. I don't know whether current framework has the right kind of implementation that may expose the 2nd issue of that. At least, from what I have run, I haven't found problems so far. -- Chen
On Mon, Aug 3, 2009 at 2:10 AM, Yi Sun <[email protected]> wrote: > Have you run the image? There should be more issues, the 10482 was not > fixed yet (not sure about today's status), the init.rc has new entries need > to add .... > Yi > > > On Sun, Aug 2, 2009 at 3:21 AM, Chen Yang <[email protected]> wrote: > >> Just finished one round of proof build of the public AOSP code: >> here is the summary: >> 1.missing one _BYTE_ORDER define in >> bionic/arch-x86/include/machine/_types.h >> >> --- a/libc/arch-x86/include/machine/_types.h >> +++ b/libc/arch-x86/include/machine/_types.h >> @@ -119,5 +119,6 @@ typedef void * __wctype_t; >> /* Feature test macros */ >> #define __HAVE_CPUINFO >> #define __HAVE_MUTEX >> +#define _BYTE_ORDER _LITTLE_ENDIAN >> >> #endif /* _I386__TYPES_H_ */ >> >> 2. some problem on x86 by recent check in dalvik: >> project dalvik/ >> diff --git a/vm/oo/Class.c b/vm/oo/Class.c >> index a5d42eb..c47dff4 100644 >> --- a/vm/oo/Class.c >> +++ b/vm/oo/Class.c >> @@ -4276,13 +4276,13 @@ noverify: >> */ >> assert(f->byteOffset >= CLASS_SMALLEST_OFFSET); >> assert((f->byteOffset & (CLASS_OFFSET_ALIGNMENT - 1)) == 0); >> +#define CLASS_BIT_SHIFT_COUNT(byteOffset) (((unsigned int)(byteOffset) - >> CLASS_SMALLEST_OFFSET) / CLASS_OFFSET_ALIGNMENT) >> + if(CLASS_BIT_SHIFT_COUNT(f->byteOffset) >= CLASS_BITS_PER_WORD) { >> + clazz->refOffsets = CLASS_WALK_SUPER; >> + break; >> + } >> u4 newBit = CLASS_BIT_FROM_OFFSET(f->byteOffset); >> - if (newBit != 0) { >> - clazz->refOffsets |= newBit; >> - } else { >> - clazz->refOffsets = CLASS_WALK_SUPER; >> - break; >> - } >> + clazz->refOffsets |= newBit; >> f++; >> } >> } >> >> 3. applypatch depends on libmtdutils.a, which doesn't exsit on x86. so >> maybe can disable it. >> project build/ >> diff --git a/tools/applypatch/Android.mk b/tools/applypatch/Android.mk >> index fe317ff..8f494b6 100644 >> --- a/tools/applypatch/Android.mk >> +++ b/tools/applypatch/Android.mk >> @@ -14,6 +14,7 @@ >> >> ifneq ($(TARGET_SIMULATOR),true) >> >> +ifeq ($(TARGET_ARCH),arm) >> LOCAL_PATH := $(call my-dir) >> include $(CLEAR_VARS) >> >> @@ -48,4 +49,5 @@ LOCAL_STATIC_LIBRARIES += libz >> >> include $(BUILD_HOST_EXECUTABLE) >> >> +endif # TARGET_ARCH == arm >> endif # !TARGET_SIMULATOR >> >> 4. preloaded-classes/init.rc fixes originally known to x86. >> >> hope it helps. >> -- >> Chen >> >> >> On Thu, Jul 30, 2009 at 3:10 PM, Chen Yang <[email protected]> wrote: >> >>> Cool. would you like to provide some more detail about the issue? Thanks. >>> -- >>> Chen >>> >>> >>> On 7/30/09, Chih-Wei <[email protected]> wrote: >>>> >>>> >>>> The android-x86 build broken due to upstream changes (donut merged) is >>>> fixed. >>>> Now you can get a workable tree and enjoy Donut on x86. >>>> >>>> You may try to repo sync. But the changes are huge so I'm not sure >>>> whether you can succeed or not. If you encounter conflicts but don't >>>> know how to fix, I suggest you redo repo init and then sync a fresh >>>> tree. >>>> >>>> Besides, wifi support has been integrated. Ath5k, ath9k modules work >>>> fine. Other drivers need further testing. As always, test results are >>>> welcome. >>>> >>>> >>>> -- >>>> Chih-Wei >>>> Android-x86 >>>> http://code.google.com/p/android-x86/ >>>> >>> >> >> >> > > > -- > Android-x86 > http://code.google.com/p/android-x86/ > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
