Hi all, I'd like to do some tests using WebKit/GTK+ in my N810. I've built it using some information listed here [1] and here [2]. Fortunately I got to build it in my Scratchbox environment and I've installed it in my N810. But when I open http://www.gtk.org in GtkLauncher, for my surprise, I get this result [3]. When I open the same site in my desktop Linux, I can get other different result [4]. It's missing a blue background... Am I missing anything in my build process? Is there other patch related to ARM? I'm configuring WebKit with: configure --enable-video --with-hildon. I've already tested it with --disable-xslt, but I didn't get any success. My scratchbox environment is: Chinook - cs2005q3.2-glibc2.5-arm #gcc --version: sbox-arm-linux-gcc (GCC) 3.4.4 (release) (CodeSourcery ARM 2005q3-2) Thanks in advance. Afonso [1] http://maemo.webkit.org/ [2] https://lists.webkit.org/pipermail/webkit-dev/2008-January/003114.html [3] http://www.flickr.com/photos/28823089@N02/2690042373/ [4] http://www.flickr.com/photos/28823089@N02/2690042377/
2008/7/22 Afonso Costa <afonso.costa@openbossa.org>:
Hi all,
Hi!
I'd like to do some tests using WebKit/GTK+ in my N810. I've built it using some information listed here [1] and here [2].
Fortunately I got to build it in my Scratchbox environment and I've installed it in my N810. But when I open http://www.gtk.org in GtkLauncher, for my surprise, I get this result [3]. When I open the same site in my desktop Linux, I can get other different result [4]. It's missing a blue background...
Am I missing anything in my build process? Is there other patch related to ARM? I'm configuring WebKit with: configure --enable-video --with-hildon. I've already tested it with --disable-xslt, but I didn't get any success.
Judging by the symptoms, you are hitting the same issue we had and that took quite some debugging to figure out. The autotools build checks for the flex tool, but doesn't ensure it's the required version so the fact that Scratchbox has 2.5.31 and not 2.5.33 is not deemed as a problem. However, although 2.5.31 generates code that builds just fine, some bugs or other changes in that code affect the CSS parsing so that things just don't work right. For example, looking at http://www.w3schools.com/CSS/css_colors.asp should show most of the colors as black if you are hitting the same bug that we had. There are two ways to fix this, one is upgrading the scratchbox-core from http://scratchbox.org/~jhakala/unofficial/ to version 1.0.11~200805291240 (there is no official release yet with newer flex) and the other is to compile a newer flex yourself. Sources are available from here: http://flex.sourceforge.net/ -- Kalle Vahlman, zuh@iki.fi Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi
Hi Kalle, I upgraded flex in my scratchbox environment and now GtkLauncher is able to open www.gtk.org in right way. I compiled flex version 2.3.35 and I replaced the old version (/scratchbox/tools/bin/flex) by this one. Maybe put this information on http://maemo.webkit.org/ would be very helpful for other people, wouldn't be? Thank you very much. Afonso On Tue, Jul 22, 2008 at 4:00 AM, Kalle Vahlman <kalle.vahlman@gmail.com> wrote:
2008/7/22 Afonso Costa <afonso.costa@openbossa.org>:
Hi all,
Hi!
I'd like to do some tests using WebKit/GTK+ in my N810. I've built it using some information listed here [1] and here [2].
Fortunately I got to build it in my Scratchbox environment and I've installed it in my N810. But when I open http://www.gtk.org in GtkLauncher, for my surprise, I get this result [3]. When I open the same site in my desktop Linux, I can get other different result [4]. It's missing a blue background...
Am I missing anything in my build process? Is there other patch related to ARM? I'm configuring WebKit with: configure --enable-video --with-hildon. I've already tested it with --disable-xslt, but I didn't get any success.
Judging by the symptoms, you are hitting the same issue we had and that took quite some debugging to figure out. The autotools build checks for the flex tool, but doesn't ensure it's the required version so the fact that Scratchbox has 2.5.31 and not 2.5.33 is not deemed as a problem.
However, although 2.5.31 generates code that builds just fine, some bugs or other changes in that code affect the CSS parsing so that things just don't work right. For example, looking at
http://www.w3schools.com/CSS/css_colors.asp
should show most of the colors as black if you are hitting the same bug that we had.
There are two ways to fix this, one is upgrading the scratchbox-core from
http://scratchbox.org/~jhakala/unofficial/<http://scratchbox.org/%7Ejhakala/unofficial/>
to version 1.0.11~200805291240 (there is no official release yet with newer flex) and the other is to compile a newer flex yourself. Sources are available from here:
-- Kalle Vahlman, zuh@iki.fi Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi
2008/7/23 Afonso Costa <afonso.costa@openbossa.org>:
Hi Kalle,
I upgraded flex in my scratchbox environment and now GtkLauncher is able to open www.gtk.org in right way. I compiled flex version 2.3.35 and I replaced the old version (/scratchbox/tools/bin/flex) by this one.
Maybe put this information on http://maemo.webkit.org/ would be very helpful for other people, wouldn't be?
Well, flex .33 *is* in the dependency lists... ;) Rather than repeating that, I'd rather see configure.ac checking for the flex version. I'm not sure how portable the configure script is supposed to be, but for example here is an example of how to check the version when common unix tools (sed, awk) are available: https://svn.apache.org/repos/asf/quetzalcoatl/mod_python/trunk/configure.in Any comments from Alp regarding this? I can cook up a patch if using sed & awk (or just sed) is ok... -- Kalle Vahlman, zuh@iki.fi Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi
Hi Kalle, On Fri, Aug 1, 2008 at 4:47 AM, Kalle Vahlman <kalle.vahlman@gmail.com>wrote:
2008/7/23 Afonso Costa <afonso.costa@openbossa.org>:
Hi Kalle,
I upgraded flex in my scratchbox environment and now GtkLauncher is able to open www.gtk.org in right way. I compiled flex version 2.3.35 and I replaced the old version (/scratchbox/tools/bin/flex) by this one.
Maybe put this information on http://maemo.webkit.org/ would be very helpful for other people, wouldn't be?
Well, flex .33 *is* in the dependency lists... ;)
Yeah, in my first attempt I installed this version but I didn't know that was necessary to replace the scratchbox's flex version or install other updated scratchbox version. This information was too helpful for me and I think it would be helpful for other people as well. Anyway, it is already registered in webkit-devel archives ;)
Rather than repeating that, I'd rather see configure.ac checking for the flex version. I'm not sure how portable the configure script is supposed to be, but for example here is an example of how to check the version when common unix tools (sed, awk) are available:
https://svn.apache.org/repos/asf/quetzalcoatl/mod_python/trunk/configure.in
Any comments from Alp regarding this? I can cook up a patch if using sed & awk (or just sed) is ok...
-- Kalle Vahlman, zuh@iki.fi Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi
Br, Afonso
2008/8/1 Afonso Costa <afonso.costa@openbossa.org>:
Hi Kalle,
On Fri, Aug 1, 2008 at 4:47 AM, Kalle Vahlman <kalle.vahlman@gmail.com> wrote:
2008/7/23 Afonso Costa <afonso.costa@openbossa.org>:
Hi Kalle,
I upgraded flex in my scratchbox environment and now GtkLauncher is able to open www.gtk.org in right way. I compiled flex version 2.3.35 and I replaced the old version (/scratchbox/tools/bin/flex) by this one.
Maybe put this information on http://maemo.webkit.org/ would be very helpful for other people, wouldn't be?
Well, flex .33 *is* in the dependency lists... ;)
Yeah, in my first attempt I installed this version but I didn't know that was necessary to replace the scratchbox's flex version or install other updated scratchbox version. This information was too helpful for me and I think it would be helpful for other people as well.
True.
Anyway, it is already registered in webkit-devel archives ;)
I created a bug (with a patch) too: https://bugs.webkit.org/show_bug.cgi?id=20253 -- Kalle Vahlman, zuh@iki.fi Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi
participants (2)
-
Afonso Costa
-
Kalle Vahlman