- Dillo-dev - lists.mailman3.com

Re: [fltk.general] Cross-compiling Dillo to ARM
by stevegigijoe＠yahoo.com.tw July 9, 2009

July 9, 2009

Hi Alan I just found a problem around src/x11/Font_xlfd:538last week Below is my solution void fltk::setfont(Font* font, float psize) { FontSize* f = current; IFont* t = (IFont*)font; // only integers supported right now (this can be improved): psize = int(psize+.5); unsigned size = unsigned(psize); // See if the current font is correct: if(f && f->encoding && encoding_) { <<-- Suggest to add some check if (font == current_font_ && psize == current_size_ && <<-- May crash here (f->encoding==encoding_ || (!encoding_ || !strcmp(f->encoding, encoding_)))) return; } current_font_ = font; current_size_ = psize; Steve ______________________________________________________________________________________________________ ¥I¶O€~®e¶qµL€W¡HYahoo!©_Œ¯¹q€l«Hœc2.0§K¶Oµ¹§A¡A«H¥ó¥Ã»·€£¥²§R¡I http://tw.mg0.mail.yahoo.com/dc/landing

2 1

Re: [fltk.general] Cross-compiling Dillo to ARM
by darirf＠yahoo.es July 9, 2009

July 9, 2009

Hi Alan, A fellow user of the irex iliad tried to compile dillo2 for it (PXA255) and had similar issues with fltk2 (it was http://www.mobileread.com/forums/showpost.php?p=301183&postcount=84 ). Would you mind posting the configure flags that you have used for kdrive, fltk2 and dillo2? Thanks a lot. Hope that those configure also works for the iliad and we can replace the aging dillo 0.8.6 O:). Best regards and thanks again to all involved in dillo development. Dario. --- El mi?, 8/7/09, Alan Carvalho de Assis <acassis(a)gmail.com> escribi?: > De: Alan Carvalho de Assis <acassis(a)gmail.com> > Asunto: [Dillo-dev] Re: [fltk.general] Cross-compiling Dillo to ARM > Para: "Mirror of fltk.general Newsgroup" <fltk(a)easysw.com> > CC: "dillo-dev" <dillo-dev(a)dillo.org> > Fecha: mi?rcoles, 8 julio, 2009 8:58 > Hi Ian, > > On 7/8/09, imacarthur <imacarthur(a)gmail.com> > wrote: > > > > On 8 Jul 2009, at 16:33, Alan Carvalho de Assis > wrote: > > > > fltk-2 is not my strong suit, so what follows is just > guesswork > > really. However, here are some questions that might be > relevant: > > > > What fonts does your target system actually have > installed? Which > > names, what types, etc.? > > > > Now, the reason I ask is that I see from the gdb trace > that your > > program crashed in Font_xlfd.cxx, so presumably it was > attempting to > > load an "old style" XLFD font. > > > > You say your test build works with fltk-1.3, and it > defaults to using > > "new-style" XFT fonts, rather than using XLFD fonts > (although it can > > also use XLFD fonts, *or* can be built to only use > XLFD fonts by > > passing --disable-xft to configure at build time.) > > > > So... I'm guessing that the fltk-1.3 build works for > some reason > > because it is using XFT and the fltk-2 build fails > because it > > attempts to use XLFD. Does that seem feasible? > > > > If so, it might be worth trying to make sure the > fltk-2 build loads > > an XFT rather than XLFD font, see how that goes. > > > > All that said, however, a default flrk-2 build *ought* > to default to > > XFT enabled anyway - unless someone has changed that? > > > > Did you later that setting during config by any > chance? Maybe that is > > somewhere to start looking, if nothing else... > > > > You are right, I compiled Xorg (kdrive) with > "--enable-builtin-fonts", > then FLTK2 doesn't work. > > I think FLTK2 could to work with only "fixed" font, just > like FLTK1 does. > > Thank you very much! > > Regards, > > P.S.: Dillo is working fine on i.MX27 now! > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

2 1

(no subject)
by acassis＠gmail.com July 9, 2009

July 9, 2009

Hi All, I am trying to port Dillo to i.MX27 (ARM9) processor. Using LTIB build system (www.ltib.org) to cross-compile FLTK. I cross-compiled FLTK2, but it is crashing, I can't run any demo example. To FLTK1.3 everything works fine, I ran all examples successfully. To FLTK2 nothing works. I searched Internet for similar error, but nothing solves it. I tested these FLTK revision: fltk-2.0.x-r6793 fltk-2.0.x-r6101 It appears to crash at "fltk::setfont". In fact I can see "bad font: fixed" message just before that "Segmentation Fault". Could someone give me some suggestion to solve this issue? See below the gdb backtrace. I am running gdbserver on i.MX27 board (IP 192.168.0.180) Best Regards, Alan $ arm-elf-gdb /home/alan/ltib/rootfs/home/test/hello GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"... (gdb) target remote 192.168.0.180:3333 Remote debugging using 192.168.0.180:3333 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. 0x400007e0 in ?? () (gdb) set solib-absolute-prefix /home/alan/ltib/rootfs (gdb) b main Breakpoint 1 at 0xb9e8: file hello.cxx, line 9. (gdb) c Continuing. Breakpoint 1, main (argc=1, argv=0xbeaa5e44) at hello.cxx:9 9 Window *window = new Window(300, 180); (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x4025dfe0 in strcmp () from /home/alan/ltib/rootfs/lib/libc.so.6 (gdb) bt #0 0x4025dfe0 in strcmp () from /home/alan/ltib/rootfs/lib/libc.so.6 #1 0x0000d1e4 in fltk::setfont (font=0x3a0ac, psize=12) at x11/Font_xlfd.cxx:542 #2 0x0001ac80 in fltk::Widget::draw_box (this=0x40b68, r=@0xbeaa5a18) at Widget_draw.cxx:94 #3 0x0001acc0 in fltk::Widget::draw_box (this=0x0) at Widget_draw.cxx:88 #4 0x0001a810 in fltk::Widget::draw (this=0x0) at Widget.cxx:644 #5 0x0000d618 in fltk::Group::draw_child (this=<value optimized out>, w=@0x40b68) at Group.cxx:750 #6 0x0000e218 in fltk::Group::draw (this=0x406e0) at Group.cxx:682 #7 0x00013ff8 in fltk::Window::flush (this=0x406e0) at x11/run.cxx:2566 #8 0x000116d4 in fl_window_flush (window=0x406e0) at run.cxx:657 #9 0x00011784 in fltk::flush () at run.cxx:691 #10 0x00016a60 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:484 #11 0x00016b8c in fltk::run () at run.cxx:397 #12 0x402071cc in __libc_start_main () from /home/alan/ltib/rootfs/lib/libc.so.6 #13 0x0000b94c in _start () (gdb)

2 2

Re: [fltk.general] Cross-compiling Dillo to ARM
by acassis＠gmail.com July 8, 2009

July 8, 2009

Hi Ian, On 7/8/09, imacarthur <imacarthur(a)gmail.com> wrote: > > On 8 Jul 2009, at 16:33, Alan Carvalho de Assis wrote: > > fltk-2 is not my strong suit, so what follows is just guesswork > really. However, here are some questions that might be relevant: > > What fonts does your target system actually have installed? Which > names, what types, etc.? > > Now, the reason I ask is that I see from the gdb trace that your > program crashed in Font_xlfd.cxx, so presumably it was attempting to > load an "old style" XLFD font. > > You say your test build works with fltk-1.3, and it defaults to using > "new-style" XFT fonts, rather than using XLFD fonts (although it can > also use XLFD fonts, *or* can be built to only use XLFD fonts by > passing --disable-xft to configure at build time.) > > So... I'm guessing that the fltk-1.3 build works for some reason > because it is using XFT and the fltk-2 build fails because it > attempts to use XLFD. Does that seem feasible? > > If so, it might be worth trying to make sure the fltk-2 build loads > an XFT rather than XLFD font, see how that goes. > > All that said, however, a default flrk-2 build *ought* to default to > XFT enabled anyway - unless someone has changed that? > > Did you later that setting during config by any chance? Maybe that is > somewhere to start looking, if nothing else... > You are right, I compiled Xorg (kdrive) with "--enable-builtin-fonts", then FLTK2 doesn't work. I think FLTK2 could to work with only "fixed" font, just like FLTK1 does. Thank you very much! Regards, P.S.: Dillo is working fine on i.MX27 now!

1 0

.deb files as PPA
by jcid＠dillo.org July 7, 2009

July 7, 2009

Hi, Now that launchpad is back, .deb packages for Debian and Ubuntu are available from our download page. -- Cheers Jorge.-

2 1

client-side redirect
by corvid＠lavabit.com July 5, 2009

July 5, 2009

I went to http://home.williampoundstone.net/Keeler/ and it breaks because there's a space before the URL in <meta http-equiv="refresh" content="0;url= Home.html" /> I can't seem to find anything that does a careful job of specifying what's legal here.

1 0

dillo-2.1.1 released
by corvid＠lavabit.com July 5, 2009

July 5, 2009

The purpose of this release is to prevent a maliciously-crafted image from causing an overflow. Since this is a matter of security, everyone is, naturally enough, encouraged to upgrade :) Thanks go to the oCERT folks for bringing the matter to our attention. (Jorge will send the freshmeat announcement in a little bit, and I will finish updating the website in a moment...)

4 4

dillo 2.1]
by sandshrew＠gmail.com July 4, 2009

July 4, 2009

Accidentally sent to corvid only. Forwarding to dillo-dev. > > > It seems whoever designed the new website theme has no idea what > > > READABILITY means... It looks like someone just used some stupid online > > > color picker, which just picks some similar colors to the one user > > > chooses. The old website looked MUCH MUCH better. Imho, it's a > > > regression... > > > > Hm I like the new design, but I agree that readability might be a problem. > > Let's see what other say. > > I still find visited text to be hard to read, but I know I should > break down and get a new display... > I wonder if you are the only dillo user with old display... BTW, I am using pretty new LCD display and still find it hard to read.

4 7

Tango icon theme for Dillo 2.1.1
by xentalion＠gmail.com July 4, 2009

July 4, 2009

Skipped content of type multipart/alternative

2 2

dillo 2.1.1
by corvid＠lavabit.com July 3, 2009

July 3, 2009

We're planning a bugfix release because it turns out that the PNG image size fix added right before the 2.1 release was incorrect. The nominal release date is Friday, but of course we'll see... Considering how I ripped out a bunch of extraneous system includes right after the 2.1 release, it would be a comfort to know that the code in the repository still compiles for everyone.

5 6