[poky] web2 on PPC

Wed Oct 5 08:10:24 PDT 2011

On 2011-10-05 07:53, Gary Thomas wrote:
> On 2011-10-05 07:44, Richard Purdie wrote:
>> On Tue, 2011-10-04 at 10:19 -0600, Gary Thomas wrote:
>>> On 2011-10-04 10:11, Khem Raj wrote:
>>>> On 10/4/2011 6:14 AM, Gary Thomas wrote:
>>>>> On 2011-10-03 14:14, Khem Raj wrote:
>>>>>> On 10/3/2011 7:59 AM, Gary Thomas wrote:
>>>>>>> On 2011-09-30 14:15, Gary Thomas wrote:
>>>>>>>> I'm trying to run the web-webkit browser on my PowerPC system (built
>>>>>>>> using Poky).
>>>>>>>> I've built this on ARM and it runs great, but on PowerPC it fails
>>>>>>>> almost immediately.
>>>>>>>> Following into the failure with GDB, it looks like it's trying to
>>>>>>>> build up a string
>>>>>>>> using a [possibly] wide character iterator. It fails on line 76 of the
>>>>>>>> code below,
>>>>>>>> going through it by hand shows that 'iterator' is NULL.
>>>>>>>>
>>>>>>>> (gdb) dir
>>>>>>>> /local/logopak8347tbga_new/tmp/work/ppc603e-amltd-linux/webkit-gtk-1.5.1+svnr90727-r0
>>>>>>>>
>>>>>>>>
>>>>>>>> (gdb) l
>>>>>>>> 71 TextBreakIterator* acquireLineBreakIterator(const UChar* string,
>>>>>>>> int length, const AtomicString& locale)
>>>>>>>> 72 {
>>>>>>>> 73 UBreakIterator* iterator =
>>>>>>>> LineBreakIteratorPool::sharedPool().take(locale);
>>>>>>>> 74
>>>>>>>> 75 UErrorCode setTextStatus = U_ZERO_ERROR;
>>>>>>>> 76 ubrk_setText(iterator, string, length,&setTextStatus);
>>>>>>>> 77 if (U_FAILURE(setTextStatus)) {
>>>>>>>> 78 LOG_ERROR("ubrk_setText failed with status %d", setTextStatus);
>>>>>>>> 79 return 0;
>>>>>>>> 80 }
>>>>>>>> (gdb) b 75
>>>>>>>> Breakpoint 1 at 0xf8a7440: file
>>>>>>>> Source/WebCore/platform/text/TextBreakIteratorICU.cpp, line 75.
>>>>>>>>
>>>>>>>> Any ideas what might be wrong here? Maybe some confusion about wide vs
>>>>>>>> not-wide
>>>>>>>> character representation (I've seen this one a lot, especially on
>>>>>>>> PowerPC systems)?
>>>>>>>> Any clues where to look next?
>>>>>>>> I did note that 'locale' into this function is also NULL.
>>>>>>>>
>>>>>>>> Should I file a bug?
>>>>>>>>
>>>>>>>> Note: I tried this with the stock Poky master
>>>>>>>> 9d1db6cc928199f8ac4960e8d4648563ef141427
>>>>>>>> building for qemuppc and running web2 via ssh -X (since qemu doesn't
>>>>>>>> support graphics?)
>>>>>>>> The failure is the same, so this is not something special in my setup.
>>>>>>>>
>>>>>>>> Note 2: it's difficult to get this to fail when running in qemu since
>>>>>>>> it only fails
>>>>>>>> when it's loading and rendering the www.google.co.uk default page. I
>>>>>>>> couldn't figure
>>>>>>>> out how to get my qemu system to be able to access that page over the
>>>>>>>> net, but I ran
>>>>>>>> the same Yocto filesystem on my hardware (this is not a hardware bug)
>>>>>>>> with the same
>>>>>>>> failure. Maybe someone smarter than me can show me how to get qemu to
>>>>>>>> actually access
>>>>>>>> the internet (when the machine that's running qemu is inside a NAT'd
>>>>>>>> zone)?
>>>>>>>>
>>>>>>>> Thanks for any help/ideas
>>>>>>>>
>>>>>>>
>>>>>>> Filed as http://bugzilla.pokylinux.org/show_bug.cgi?id=1570
>>>>>>>
>>>>>>> Still looking for ideas on where to look, how to debug this.
>>>>>>
>>>>>> such problems can happen when autoconf variables are not cached with
>>>>>> right values. So look into site files. What variables to look for can be
>>>>>> taken from config.log of the package.
>>>>>>
>>>>>
>>>>> It turns out the problem is that the ICU library does not work
>>>>> properly (at all!) when the host and target systems have different
>>>>> endianness. If I install ICU libraries which were built on a
>>>>> native PowerPC system, the 'web2' program works.
>>>>>
>>>>
>>>> compare the configure outputs of icu between cross and native ppc build
>>>
>>> I have - they are totally broken in the cross-compile setup.
>>>
>>> The ICU library has a tool which is used to covert their internal
>>> data base to the proper endianness. However, it only works properly
>>> when converting _to_ the endianness of the machine it runs on. It will
>>> not convert a little endian data base to a big endian version when the
>>> tool is run on a little endian machine. I tried to get the ICU folks
>>> to fix this more than a year ago, but they weren't interested in this
>>> case.
>>
>> Is there much needed to make this tool work across different endians? It
>> depends what its doing I guess...
>
> It's a horrible mess :-( I've spent a number of days trying to get this
> thing working with no luck. As I said, I got little joy from the upstream
> folks - they don't seem to be concerned that this doesn't work properly.
> Maybe if they were contacted from someone with more clout (Intel?), they'd
> be more interested.
>
>>
>>> I think I have a solution, albeit a bit crude. The ICU library builder
>>> can take a properly ordered data base as input and not do any of this
>>> mucking around. In fact, the library ships with the little endian version
>>> which is used untouched on little endian targets. I can produce the big
>>> endian version and just provide it to the recipe. One problem with this
>>> is that it's HUGE - 18MB, so I'm not quite sure where to put it.
>>
>> Is that compressed?
>
> Compressed it's less than 7MB.
>
>>
>> I'd be prepared to host that on the Yocto web server so that we can fix
>> the big endian builds for now although its not really a long term
>> solution...
>
> The only "solution" I've come up with so far is to simply replace one
> of the libraries that gets built with one that works. There doesn't
> seem to be any way to get the existing build system to create the library
> properly. I'll package up what I have and send a pointer for review.

Recipe and data file (working library) attached to http://bugzilla.pokylinux.org/show_bug.cgi?id=1570


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------