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. 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)?
Further investigation shows that this is a failure in the ICU library. Webkit is using ICU to help it render strings and the calls to 'ubrk_open()' always return NULL. This is because of how the ICU library is built. It contains some prebuilt tables which are target specific. If the host and target have different endianness (or indeed other layout issues), this fails. I built the ICU library (version 3.6) by hand on a PowerPC host and installed this to my Poky system. Now 'web2' runs fine. Newer versions of ICU supposedly handle this case where the host and target are not the same endianness. However, my experience with version 4.4 in the past showed that the situation was not any better. I'll try the latest 4.8.1 to see if it helps.
ICU 4.8.1 still fails under these conditions :-(
Created attachment 270 [details] Updated recipe for ICU library Includes PowerPC work around. Actual data file can be found at: http://www.mlbassoc.com/poky/libicudata.so.48.1.gz
Please take some action on the bug, at least accept the bug
Gary, There is nothing special about getting to internet from qemu. if you are behind proxies then you will need to setup the proxies inside qemu. Nitin
Gary, I see you have a binary file with powerpc work around. Why don't you apply patches for the work around to the recipe in poky? Nitin
(In reply to comment #6) > Gary, > I see you have a binary file with powerpc work around. Why don't you apply > patches for the work around to the recipe in poky? > > Nitin It's not that simple - the work around is to provide a database library which is in the correct endian format. If you are building this recipe on a little endian machine (most everyone is), the library created is incorrect when used on big endian targets. The ICU build process attempts to get this right, but it's not even close and upstream doesn't seem too interested in making it work :-(
Gary, Can you scope out how much work is needed to support correct endian-ness in a cross build? 1. If it is not too much work then support can be added to ICU to swap the bytes for correct endian-ness. 2. If it is too much work, then it can be build with mips qemu emulation, which will be built much slowly but correctly. 3. And also another option is what you have, provide prebuilt library from some url. Nitin
(In reply to comment #8) > Gary, > Can you scope out how much work is needed to support correct endian-ness in a > cross build? > 1. If it is not too much work then support can be added to ICU to swap the > bytes for correct endian-ness. > 2. If it is too much work, then it can be build with mips qemu emulation, > which will be built much slowly but correctly. > 3. And also another option is what you have, provide prebuilt library from > some url. > > Nitin There is already code for option (1) but it's severely broken and would take a significant amount of time to redo (probably start from scratch) Option (2) would be OK - not sure why you'd choose MIPS instead of PowerPC? I'd hate to have to build a complete MIPS setup when I build for PowerPC, just to solve this issue :-( I prefer option (3) as I already have it working and tested. It only requires updating the library manually when the recipe changes. Given that the OE-core recipe is still at 3.6 (I've tested 4.8.1 here) and that this project changes very rarely, I think this would be the way to go.
I meant powerpc in place of mips. (for me mips and ppc are equally foreign, hence the confusion)
Gary, the 3rd options is the hardest to get included in the tree though.
Its too late to get this into 1.2, targeting to point release.
Gary, I investigated ICU, and found it's not easy to add this feature. But we can configure webkit-gtk to use glib as unicode backend rather than icu as attached patch. Some comments says glib's unicode is incomplete, so can you have a test on your real machine(need change my patch a little bit) when you have time? If it works, we can use it as temporary solution before this feature is added in ICU upstream.
Created attachment 491 [details] Fix web2 segfault on ppc configure webkit-gtk to use glib rather than icu as unicode backend to avoid segfault
Currently our ppc board mpc8315e-rdb doesn't support X because it does't have any graphics adaptor, so we can not verifiy it on real hardware. But I can reproduce this bug on qemuppc because it supports X now. We need to re-configure the qemu network to make it can access internet: ###### 1. On linux host, enable the ip forwarding: $ echo 1 > /proc/sys/net/ipv4/ip_forward If there is a firewall on the host, we also need to run the following command: $ iptables -t nat -A POSTROUTING -j MASQUERADE 2. Launch the qemuppc image. 3. We need to re-configure the network manually. First, kill the connmand: $ killall connmand $ ifconfig eth0 192.168.7.2 $ ifconfig eth0 up Then add a default gw: $ route add default gw 192.168.7.1 dev eth0 4. Add a nameserver in /etc/resolv.conf 5. Launch the web2 in terminal. Then the brower could access the internet. ######## I built a qemuppc sato-image with the latest master branch(b4c8c74a45e386f99344cf9799eb5294ad6c9e3e). When I access some complicated website, like www.intel.com or www.nvidia.com. There would be a segfault with it. After applying Edwin's patch, the web2 works fine. But there is still some issues, someone has opened a bug 2318 to report it.
(In reply to comment #9) Gary, I have sent you a mail, could you pls. test the attached patch to see if it works? Thanks, Edwin
Yes, this change does work (tested with the attached patch). Perhaps the changes in the patch should just be used for all architectures? No need to mess with the ICU package (broken) when pango can work just as well.
(In reply to comment #17) > Yes, this change does work (tested with the attached patch). > > Perhaps the changes in the patch should just be used for all architectures? > No need to mess with the ICU package (broken) when pango can work just as > well. I'm not sure if glib unicode works for all architectures. Furthermore, readme in glib said its unicode implementation is incomplete at this point. So I'd like to use this work around only for ppc and turn to ICU if they fix this issue, or glib if it become more popular. Do you agree? Is your machine config in oe-core? Or you need something like bbappend in your layer. Thanks, Edwin
(In reply to comment #18) > (In reply to comment #17) > > Yes, this change does work (tested with the attached patch). > > > > Perhaps the changes in the patch should just be used for all architectures? > > No need to mess with the ICU package (broken) when pango can work just as > > well. > > I'm not sure if glib unicode works for all architectures. Furthermore, > readme in glib said its unicode implementation is incomplete at this point. > So I'd like to use this work around only for ppc and turn to ICU if they fix > this issue, or glib if it become more popular. Do you agree? Fair enough - for machines that share the same endian-ness as the build host (typically little endian machines) this is acceptable. What I don't like about it is that the program will be built differently, hence behave differently, on different target architectures (seldom a correct choice) > > Is your machine config in oe-core? Or you need something like bbappend in > your layer. No, my machine is not public. At this point, I just have edited the main recipe directly (matching your request).
Patch to use glib as unicode backend is already in master, so there is no crash from web browser on ppc. http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=348da93e283b2b8454fd9cde80d4b17378e2a168 For the ICU bug, we need keep tracking the upstream status for a fix. I'd suggest postpone it to a later milestone. Thanks, Edwin
We have a work around to fix the browser crash on ppc system, and wait for ICU's community to fix this cross-compile issue. Postpone it to 1.4.
Created attachment 569 [details] Extend fix for all PowerPC targets
Gary's patch was applied a while ago, and Webkit is working on qemuppc. We are still waiting for the upstream to provide a proper patch, there are various cross-compilation and endianness bugs at http://bugs.icu-project.org/trac, I am not exactly sure if gary or edwin actually filed bugs. I also agree with Gary, we might make full build use pango for all arches and see what happens, I will test this.
A relevant upstream bug is http://bugs.icu-project.org/trac/ticket/11758. Open for 57 months.
commit 77d1b9cda69d09cd7d3c8174ef14b4ee10e5efb6 Author: Yi Zhao <yi.zhao@windriver.com> Date: Tue Dec 5 09:17:04 2017 +0800 icu: fix libicudata corruption on big endian system