Honeycomb GPL and LGPL bits.

[Jean-Baptiste Queru]

I've released the source code for the GPL and LGPL components of the
Android platform that have been shipped as binaries in various
Honeycomb/3.0 builds, as usual.

Because this is not a full code drop of the entire Android platform,
building those components takes a tiny bit more effort than usual.
There's no manifest to directly get to them. However, checking them
out on top of the current master branch allows to compile and link
them.

Because the master branch changes over time, there's a possibility
that future versions of the master branch could become incompatible
with those GPL and LGPL components from 3.0. In order to continue
being able to build those components without pain, I've captured the
current state of master in a manifest called 3.0-base.xml.

Al Sutton was kind enough to write detailed step-by-step instructions
on his blog at http://blog.alsutton.com/2011/04/12/android-honeycomb-source-drop/

In summary:

-get 3.0-base: repo init -u
git://android.git.kernel.org/platform/manifest.git -m 3.0-base.xml ;
repo sync

-get the GPL/LGPL source code on top of that: repo forall -p -c git
checkout android-3.0_r1.3

-do a build (you might want to do a clean build, i.e. start with make
clobber before your regular make).

Note1: As far as I know this also currently works on a plain master
client, no need to switch to 3.0-base.xml, but might break in the
future.

Note2: You can switch back and forth between the true master and
3.0-base with repo init -m 3.0-base.xml ; repo sync and repo init -m
default.xml ; repo sync.

Note3: The code compiles and builds, but might not run (webkit
definitely crashes during initialization, other components haven't
been thoroughly tested).

Here's how the build numbers match the various tags:
HRI39: android-3.0_r1
HRI66: android-3.0_r1.1
HWI69: android-3.0_r1.2
HRI93: android-3.0_r1.3
The android-sdk-3.0-pre and android-sdk-3.0_r1 tags are hopefully
self-explanatory

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.

[allstars]

Hi

I try to download the source you mentioned and try to build it

but I got the following error when building webkit(libwebcore.a)

make: execvp: /bin/bash: Argument list too long
make: *** [out/target/product/generic/obj/STATIC_LIBRARIES/
libwebcore_intermediates/libwebcore.a] Error 127


have you met this?
or how should I shorten it?
I use 'make showcommands' to see the log
it has a lot lot lot of object files to link

thanks

On Apr 12, 11:25 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I've released the source code for the GPL and LGPL components of the
> Android platform that have been shipped as binaries in various
> Honeycomb/3.0 builds, as usual.
>
> Because this is not a full code drop of the entire Android platform,
> building those components takes a tiny bit more effort than usual.
> There's no manifest to directly get to them. However, checking them
> out on top of the current master branch allows to compile and link
> them.
>
> Because the master branch changes over time, there's a possibility
> that future versions of the master branch could become incompatible
> with those GPL and LGPL components from 3.0. In order to continue
> being able to build those components without pain, I've captured the
> current state of master in a manifest called 3.0-base.xml.
>
> Al Sutton was kind enough to write detailed step-by-step instructions

> on his blog athttp://blog.alsutton.com/2011/04/12/android-honeycomb-source-drop/

[Jean-Baptiste Queru]

I've not seen that myself. I'm using a 64-bit Ubuntu 10.04.

I've seen reports of similar issues in the past, though, and the issue
is really that the command line to link webkit is too long to pass to
the shell.

I don't have a permanent fix, or even an easy workaround. It might be
possible to rename libwebcore.a to w.a. Pushing further, renaming
generic to g might also work. None of those are easy, though :(

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

[Ying Wang]

We do have a permanent fix :-)

Here is the merge:

https://review.source.android.com/22351

[SandroB]

Maybe I'm wrong but this fix could lead to problems.

./prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-ar crs 
./out/target/product/generic/obj/STATIC_LIBRARIES/libwebcore_intermediates/libwebcore.a
./out/target/product/generic/obj/STATIC_LIBRARIES/libwebcore_intermediates/WebKit/android/nav/CachedFrame.o
./out/target/product/generic/obj/STATIC_LIBRARIES/libwebcore_intermediates/WebCore/history/CachedFrame.o

What if first CachedFrame.o (WebKit/android/nav/) is added in first

$(call _concat-if-arg2-not-empty,$(1),$(wordlist 1,500,$(2)))

and second CachedFrame.o (WebCore/history/) in
 $(call _concat-if-arg2-not-empty,$(1),$(wordlist 501,1000,$(2)))

The second one will replace the first one in libwebcore.a?
There should be also sorting by name and... checking if there is more than 500 with the same name? :)
 

[Ying Wang]

Those two CachedFrame.o are totally different and just happened to have the same name (unfortunately).

But we use the "crsP" flag of ar instead of "csr". The "P" means to consider the full path when matching file names in the archive. 

So both CachedFrame.o will be in libwebcore.a with no problem.

You can verify it with "ar t out/target/product/<product_name>/obj/STATIC_LIBRARIES/libwebcore_intermediates/libwebcore.a".

 

--

[SandroB]

You are right. The P solves possible problems.
I tried to use fix on 2.1 and there is no P flag in ARFLAGS so this problem occurs.
Thank you.

[sri]

All,

I am trying to build gingerbread with SVG support,

The moment i enable the svg i am getting this error

make: execvp: /bin/bash: Argument list too long

make: *** [out/target/product/generic/obj/STATIC_LIBRARIES/libwebcore_intermediates/libwebcore.a] Error 127

make: *** Waiting for unfinished jobs....

I know that the args are big,

Any pointers on how to cut down the list and create the libwebcore.a?

I am running fedora 13 32 bit? do i have to upgrade my os?

sri

[Ying Wang]

The issue has been fixed in aosp master, see definition of split-long-arguments in build/core/definitions.mk