[OE-core] [PATCH 1/1] webkit-gtk: Use glib as unicode backend to avoid browser crash

[Richard Purdie]

On Wed, 2012-05-30 at 12:56 -0600, Gary Thomas wrote:
> On 2012-05-30 10:40, Richard Purdie wrote:
> > On Wed, 2012-05-30 at 17:08 +0800, edwin.zhai at intel.com wrote:
> >> From: Zhai Edwin<edwin.zhai at intel.com>
> >>
> >> webkit-gtk depends on ICU for the unicode, but ICU is not safe when build and
> >> target system owns different endian. ICU's community is not responsive to make
> >> a patch for this, so glib is used as work around here.
> >>
> >> [YOCTO #1570] got fixed
> >>
> >> Signed-off-by: Zhai Edwin<edwin.zhai at intel.com>
> >> ---
> >>   meta/recipes-sato/webkit/webkit-gtk_svn.bb |   10 +++++++++-
> >>   1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > I've merged this however I'm not 100% happy with this as the final fix.
> > I'd ask that:
> >
> > a) The bug remains open (re-prioritised appropriately) about the
> > remaining issues that still exist in ICU
> > b) We add something to the ICU recipe which stops it building when the
> > endianess isn't correct (host matches target) so nobody can built it and
> > have it not work.
> 
> Why not accept my patch that provides a working dataset?  I doubt
> that you're ever going to get the ICU folks interested to the point
> of fixing this correctly and this solves the problem without the
> [IMO undesirable] side effect of using different libraries on
> different architectures (for webkit-gtk).

The issue here is that starting to distribute binary blobs gets us into
potentially troubled waters. It also means that for every new tune or
target (say mips BE), we'd need another blob. Add something like uclibc
and the problem gets worse.

So I can see the attraction of the solution and it works well for
particular cases but it isn't something I think can be made to work in
OE-Core in the general case :(.

I did wonder whether we could post process the binary to correct the
endianess of the data in the file?

Cheers,

Richard