[oe] chromium detected as stripped

[Raphael Kubo da Costa]

Hey Trevor,

Trevor Woerner <twoerner at gmail.com> writes:
> On Tue 2017-08-15 @ 11:53:42 PM, Andreas Müller wrote:
>> On Tue, Aug 15, 2017 at 6:23 PM, Raphael Kubo da Costa
>> <raphael.kubo.da.costa at intel.com> wrote:
>> > Khem Raj <raj.khem at gmail.com> writes:
>> >
>> >> what are main architectures targetted with crosswalk ? I think scope is
>> >> important, since meta-browser supports, almost all oe-core supported
>> >> architectures. including x86/arm/mips/ppc, any cross build patches are
>> >> required in anycase, but architecture patches will be additional if you
>> >> were only considering a subset of architectures.
>
> I was wondering the same thing myself :-) This recipe lists "armv7a" in
> COMPATIBLE_MACHINE but the (32-bit version of) raspberrypi3, for
> example, is armv7ve. Therefore I get:
>
> 	ERROR: Nothing PROVIDES 'chromium'
> 	chromium was skipped: incompatible with machine raspberrypi3 (not in COMPATIBLE_MACHINE)

I've just pushed a change to my chromium61 branch that adds support for
armv7ve. I've also completed a full Chromium build there with
MACHINE="raspberrypi3" (I didn't run it though).

I also pushed some other GN-related fixes for ARM platforms to ensure we
don't end up passing incompatible -mcpu and -march values to the
compiler.

>> > With that said, I've tested my builds with x86, x86-64, ARMv7 (IIRC
>> > Chromium doesn't support earlier ARM processors) and aarch64.
>
> Can you provide a list of "MACHINE = ..." that were used?

If I still recall everything correctly, I've tested different versions
with the following MACHINEs (with either Yocto Pyro or previous releases):

* intel-corei7-64
* qemuarm (I had to change the tune file to avoid using ARMv5).
* qemuarm64
* qemux86
* qemux86-64
* raspberrypi3

> The problem I was having was in trying to force the build system to use the
> toolchain I wanted it to use. The Igalia people solved this problem by
> tricking the build system to think it was building for CrOS, and then
> redefining the toolchain for CrOS to use the toolchain generated by OE. This
> worked for x86_64 (minnowboard) but would fail for the raspberrypi3 with
> "illegal instruction". So somewhere in the build, the specified toolchain was
> being ignored and the host's toolchain was being used instead.

I think I solved this early on in my recipe. In general, in the GN world
Chromium works with 3 different toolchains: a host one (equivalent to
OE's build host, for tools that are supposed to run on the system
building Chromium), a target one (for the target platform) and one for
producing V8 snapshot files (what snapshot files are is not relevant
here). The V8 snapshot toolchain runs on the host system, but must have
the same "bit-width" as the target system (so a x86-64 host targeting
ARMv6 must produce and run an i586 binary during the build).

In my recipe, I've worked around the need for the V8 snapshot toolchain
by pointing it to the target toolchain and then running the required
binaries with qemu-wrapper. The host and target toolchains are specified
as GN files, and they also set the right compiler/linker options etc.
Part of the process will be simplified once M62 reaches the stable
channel, as one of the Chromium developers (who also happens to be a
Gentoo packager) landed a change that simplifies setting up custom
toolchains.

> I'd be happy to work on trying to integrate Raphael's excellent work into
> meta-browser. However, it depends on nodejs, and nodejs is currently failing
> to build (Martin's "State of Bitbake World" just exploded in the last
> iteration). I'm looking into that now, somewhat. node hasn't been happy since
> the switch to gcc7.

I've got some time to work on this again. I've taken a look at the
meta-browser recipes and checked how they differ from mine; help merging
the recipes will certainly be appreciated :-)