Building the 3.1 GPL code.

[Jean-Baptiste Queru]

For people who want to work with the GPL code that was released with
3.1, here are a few pointers:

-Option 1: for all projects except chromium and webkit, the 3.1 GPL
code was merged into the AOSP master with the contributions that were
made to those projects. You might find that this is a convenient way
to work with those.

-Option 2: for all projects, including chromium and webkit, there's a
tag android-3.1_r1 that points to the exact commit that was used to
build version HMJ37 that's shipping on Xoom. For any such project, you
can run "git checkout android-3.1_r1" to get that exact version
(beware of cross-project dependencies, especially between webkit and
chromium). To do it for all projects, run "repo forall -p -c git
checkout android-3.1_r1".

-Option 3: even though it's possible today to build the 3.1 GPL code
on top of the latest master, that might not be the case forever since
master moves ahead fast. In order to be able to continue building the
3.1 GPL code in the future, I've created a manifest called
"3.1-base.xml" that contains the exact state of master as it was
yesterday. You can switch to it with "repo init 3.1-base.xml ; repo
sync", and from there apply the steps in Option 2. Get back to your
plain master with "repo init -m default.xml ; repo sync".

A word of caution, especially around webkit: even though the current
AOSP master (and 3.1-base) contains interface definition files that
allow building that GPL source code, it's likely that there could be
various kinds of compatibility issues trying to run the resulting
binaries: webkit uses non-public Android APIs written in C++, and
that's likely to trigger issues of Fragile Base Class.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Jean-Baptiste Queru]

Just to make sure that there aren't any doubts, the GPL code for the
3.0 variants is still available. The tags you want are:
HRI39: android-3.0_r1
HRI66: android-3.0_r1.1
HWI69: android-3.0_r1.2
HRI93: android-3.0_r1.3
And you can use the 3.0-base.xml manifest to make sure that you can
build that code.

JBQ

[SandroB]

If I libwebcore.so build on tag android-3.1_r1,
put between libs that comes with 3.1 emulator that
I downloaded with AVD manager, (adb pull /system/lib)

prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/arm-eabi/bin/ld
libwebcore.so -rpath=.

I get errors:

libwebcore.so: undefined reference to
`SkImageDecoder::decode(SkStream*, SkBitmap*, SkBitmap::Config,
SkImageDecoder::Mode)'
libwebcore.so: undefined reference to
`SkCanvas::setBitmapDevice(SkBitmap const&)'
libwebcore.so: undefined reference to `SkBlurMaskFilter::Create(float,
SkBlurMaskFilter::BlurStyle)'
libwebcore.so: undefined reference to
`SkCanvas::commonDrawBitmap(SkBitmap const&, SkMatrix const&, SkPaint
const&)'
libwebcore.so: undefined reference to
`SkBlurDrawLooper::SkBlurDrawLooper(float, float, float, unsigned
int)'

I must be doing something wrong...

[Jean-Baptiste Queru]

That's the kind of Fragile Base Class issue that can happen with C++.
Even though both AOSP and Honeycomb expose APIs that allow the exact
same Webkit LGPL code to compile and link, binaries compiled with one
version of the API don't necessarily work with a library compiled with
a different version the API.

JBQ

> --
> You received this message because you are subscribed to the "Android Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en

[SandroB]

Thank you for answer.
Is there any tag for <AVD manager 3.1 emulator build> ?
Probably not in public git yet...

[Jean-Baptiste Queru]

Only the GPL parts have been tagged, and they're identical with the
HMJ39 release build.

JBQ

[SandroB]

Thank you for answer.

[Jae]

Hi there,

I tried to build the whole system (android-3.1_r1) following Option 3
JBQ suggested, but in vain. More specifically, I did the following:

$ cd $WORK
$ repo init -u git://android.git.kernel.org/platform/manifest.git -m
3.1-base.xml
$ repo sync
$ repo forall -p -c git checkout android-3.1_r1

$ . build/envsetup.sh
$ lunch full_crespo-userdebug
$ make -j8
============================================
PLATFORM_VERSION_CODENAME=AOSP
PLATFORM_VERSION=AOSP
TARGET_PRODUCT=full_crespo
TARGET_BUILD_VARIANT=userdebug
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=OPENMASTER
============================================

(Build begins..)

The build fails with the following error (I tried full-eng, but the
result is the same):

In file included from external/webkit/WebCore/bindings/v8/
ScriptController.h:38,
from external/webkit/WebCore/page/Frame.h:37,
from external/webkit/WebKit/android/jni/
WebCoreJniOnLoad.cpp:39:
external/webkit/WebCore/bindings/v8/V8Proxy.h: In function
'v8::Handle<v8::Primitive> WebCore::throwError(const char*,
WebCore::V8Proxy::ErrorType)':
external/webkit/WebCore/bindings/v8/V8Proxy.h:411: error:
'IsExecutionTerminating' is not a member of 'v8::V8'
external/webkit/WebCore/bindings/v8/V8Proxy.h: In function
'v8::Handle<v8::Primitive>
WebCore::throwError(WebCore::ExceptionCode)':
external/webkit/WebCore/bindings/v8/V8Proxy.h:418: error:
'IsExecutionTerminating' is not a member of 'v8::V8'
external/webkit/WebCore/bindings/v8/V8Proxy.h: In function
'v8::Handle<v8::Primitive> WebCore::throwError(v8::Local<v8::Value>)':
external/webkit/WebCore/bindings/v8/V8Proxy.h:425: error:
'IsExecutionTerminating' is not a member of 'v8::V8'

I can build the lastest master without an error, but somehow cannot
build android-3.1_r1. I compared the problematic file (external/webkit/
WebCore/bindings/v8/V8Proxy.h) in both checkouts to find that the one
in android-3.1_r1 is more up-to-date than the one in the lastest
master. Any thoughts??

Thanks,
Jae


**** git log V8Proxy.h (android-3.1_r1):
commit 4576aa36e9a9671459299c7963ac95aa94beaea9
Author: Shimeng (Simon) Wang <sw...@google.com>
Date: Tue Dec 7 17:22:45 2010 -0800

Merge WebKit at r73109: Initial merge by git.

Change-Id: I61f1a66d9642e3d8405d3ac6ccab2a53421c75d8

**** git log V8Proxy.h (latest master)
commit 3eb2fab210a9ae636c55b30b23bb53b130d1efb6
Author: Steve Block <steve...@google.com>
Date: Tue Feb 16 18:57:53 2010 +0000

Updates Android to reflect upstreaming of CHROMIUM and XPATH
guards in V8 bindings

See http://trac.webkit.org/changeset/54881

Change-Id: I7bf987cbdc8e88e39317551c098475d8f92cd582

[Jean-Baptiste Queru]

Good news, I wasn't able to reproduce that breakage, so I think that
the manifest and tags are correct.

Bad news, I wasn't able to reproduce that breakage, which means that
it's going to be harder to help you directly.

You may want to look at the usual suspects:
-not being on any branch (repo branches)
-not having any modified files (repo status)
-clean build (make clobber)

JBQ

[Jae W. Lee]

Hi JBQ and all,

Thanks for the reply. Unfortunately, I still hit upon the same error
after clobbering and checking (a snapshot attached at the end).

So, I looked into the two files involved in the error:
external/webkit/WebCore/bindings/v8/V8Proxy.h and
external/v8/src/v8.h. In V8Proxy.h, there are calls to
v8::V8::IsExecutionTerminating() in Lines 411, 418 and 425, but v8.h
does not declare the method. I suspect there is still a version
mismatch problem between packages. Does your V8Proxy.h still contain
calls to v8::V8::IsExecutionTerminating()? What is the commit tag used
for external/v8.git? Apparently, android-3.1_r1 is not on the tag list
of external/v8.git, so my local copy uses android-2.2.1_r1, instead.

Thanks,
Jae

$ make clobber
// clean up messages
$ repo branches
(no branches)
$ repo status
nothing to commit (working directory clean)
$ . build/envsetup.sh
including device/htc/passion/vendorsetup.sh
including device/samsung/crespo4g/vendorsetup.sh
including device/samsung/crespo/vendorsetup.sh
$ lunch full_crespo-userdebug
// printconfig
$ make -j8
// same error as previous one

[Jean-Baptiste Queru]

You need be using the version that is mentioned in 3.1-base.xml.
Webkit is very sensitive to the exact versions of the libraries it
uses directly.

repo init -m 3.1-base.xml
repo sync
repo forall -c git checkout android-3.1_r1

JBQ

[Jae W. Lee]

Thanks again for the reply, JBQ.

I tried what you suggested to find that applying "repo forall -c git
checkout android-3.1_r1" breaks platform/external/webkit.

> repo init -m 3.1-base.xml
> repo sync

This works fine, and put my copy of webkit into the version described
in 3.1-base.xml (i.e., revision
80aad5eedfe9e84cabb8540f818f7d1971ecadc3). In this version, there are
no calls to v8::V8::IsExecutionTerminating() in
external/webkit/WebCore/bindings/v8/V8Proxy.h (which is good).

> repo forall -c git checkout android-3.1_r1

Once this checkout is applied, the webkit revision becomes
5b56a98d50eaef903ecd257cc4092ae59a406533, and calls to
v8::V8::IsExecutionTerminating() appear in
external/webkit/WebCore/bindings/v8/V8Proxy.h, which break the
compilation. Could you please check whether this is consistent with
your build?

FYI, applying android-3.1_r1 does not affect platform/external/v8.

Thanks!
Jae

[Jean-Baptiste Queru]

I confirm.

In a nutshell, I've done all the testing on a full-eng build, i.e. an
emulator build, i.e. an ARMv5 build, on which we can't use V8 and have
to fall back to JavaScriptCore, because V8 requires ARMv7.

Trying to build full_crespo-userdebug fails, exactly as you've seen.
That's an ARMv7 build that uses V8.

I don't have a fix off-hand, I'm working on one. Thanks for being patient.

JBQ

[Jae W. Lee]

Thanks for your help, JBQ. Now I understand what was the problem.

Cheers,
Jae

[Jean-Baptiste Queru]

I've made a few tweaks, which should help. They seem to allow me to
build full_crespo-userdebug, which is an ARMv7 build.

From a 3.1-base system with 3.1_r1 checked out, "repo sync
platform/build platform/external/v8" should be enough to get you into
a state where things build for ARMv7.

Please let me know if that's not the case.

Thanks,
JBQ

[Jae W. Lee]

Your fix works. Thank you, JBQ!

Cheers,
Jae

[Zach Pfeffer]

Jae,

Would you mind posting the commands you ultimately used to build the
3.1 components?

For reference, the following commands worked for me:

repo init -u git://android.git.kernel.org/platform/manifest.git -m 3.1-
base.xml

repo sync
repo forall -c git checkout android-3.1_r1 # bunch of errors: error:
pathspec 'android-3.1_r1' did not match any file(s) known to git.
. build/envsetup.sh
lunch full_crespo-userdebug
make -j8

and

lunch full_crespo4g-userdebug
make -j2

I see crepo (Nexus S), crespo4g (Nexus S 4g) and passion (Nexus One)
but I don't see Xoom. Is a Xoom target buildable?

On Jun 16, 10:58 pm, "Jae W. Lee" <jaew...@gmail.com> wrote:
> Your fix works.  Thank you, JBQ!
>
> Cheers,
> Jae
>
>
>
>
>
>
>
> On Thu, Jun 16, 2011 at 9:54 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > I've made a few tweaks, which should help. They seem to allow me to
> > build full_crespo-userdebug, which is an ARMv7 build.
>
> > From a 3.1-base system with 3.1_r1 checked out, "repo sync
> > platform/build platform/external/v8" should be enough to get you into
> > a state where things build for ARMv7.
>
> > Please let me know if that's not the case.
>
> > Thanks,
> > JBQ
>

> > On Thu, Jun 16, 2011 at 3:58 PM, Jae W. Lee <jaew...@gmail.com> wrote:
> >> Thanks for your help, JBQ. Now I understand what was the problem.
>
> >> Cheers,
> >> Jae
>
> >> On Thu, Jun 16, 2011 at 6:46 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>> I confirm.
>
> >>> In a nutshell, I've done all the testing on a full-eng build, i.e. an
> >>> emulator build, i.e. an ARMv5 build, on which we can't use V8 and have
> >>> to fall back to JavaScriptCore, because V8 requires ARMv7.
>
> >>> Trying to build full_crespo-userdebug fails, exactly as you've seen.
> >>> That's an ARMv7 build that uses V8.
>
> >>> I don't have a fix off-hand, I'm working on one. Thanks for being patient.
>
> >>> JBQ
>

> >>>>>>>> Author: Steve Block <stevebl...@google.com>

> >>>>>>>> Date:   Tue Feb 16 18:57:53 2010 +0000
>
> >>>>>>>>    Updates Android to reflect upstreaming of CHROMIUM and XPATH
> >>>>>>>> guards in V8 bindings
>

> >>>>>>>>    Seehttp://trac.webkit.org/changeset/54881

> ...
>
> read more »

[Jae W. Lee]

Hi Zach,

One caveat is I did not intend to build the entire working platform
for Xoom using AOSP; I was interested only in building specific
libraries and frameworks which are functional on Xoom.

$ cd $WORK
$ repo init -u git://android.git.kernel.org/platform/manifest.git -m
3.1-base.xml
$ repo sync
$ repo forall -p -c git checkout android-3.1_r1

$ vi device/samsung/crespo/BoardConfigCommon.mk
(Change TARGET_ARCH_VARIANT from armv7-a-neon to armv7-a.)

$ . build/envsetup.sh
$ lunch full_crespo-userdebug
$ make -j8

This sequence worked for me, which means building was completed
without an error. (I haven't even tried to flash the entire system
image to the device; I am sure it won't work.)

Cheers,
Jae

[Zach Pfeffer]

On 28 June 2011 17:10, Jae W. Lee <jae...@gmail.com> wrote:
> Hi Zach,
>
> One caveat is I did not intend to build the entire working platform
> for Xoom using AOSP; I was interested only in building specific
> libraries and frameworks which are functional on Xoom.
>
> $ cd $WORK
> $ repo init -u git://android.git.kernel.org/platform/manifest.git -m
> 3.1-base.xml
> $ repo sync
> $ repo forall -p -c git checkout android-3.1_r1
> $ vi device/samsung/crespo/BoardConfigCommon.mk
> (Change TARGET_ARCH_VARIANT from armv7-a-neon to armv7-a.)
>
> $ . build/envsetup.sh
> $ lunch full_crespo-userdebug
> $ make -j8
>
> This sequence worked for me, which means building was completed
> without an error. (I haven't even tried to flash the entire system
> image to the device; I am sure it won't work.)

Actually I was interested in that as well. If we could get something
functional from using older parts of the build composed with newer
parts that would be cool.