- Dillo-dev - lists.mailman3.com

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

Hey guys, I think I'm near on getting dillo2 working on blackfin uClinux. My concurrent problem is, that there are some Errors linking the project. Undefined reference ..... I'll give you my compile log: make[3]: F?r das Ziel ?all? ist nichts zu tun. make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' bfin-linux-uclibc-g++ -I.. -I/home/mheiser/uClinux/uClinux/uclinux-dist/staging/usr/include/libpng12 -I/home/mheiser/fltk-2.0.x-r6841 -I/home/mheiser/uClinux/uclinux-dist/staging/usr/include/freetype2 -I/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45/X11/include -Wno-non-virtual-dtor -O2 -pipe -isystem /home/mheiser/uClinux/uclinux-dist/staging/usr/include -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -lpng12 -L/home/mheiser/fltk-2.0.x-r6841/lib -Wl,-rpath,/home/mheiser/bfin-fltk2/lib -lfltk2_images -lpng -lfltk2_images -ljpeg -lz -lfltk2 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/src/lib -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz -liconv /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_Xutf8LookupString' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XFreeDeviceList' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_wcstombs' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_mbstowcs' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XOpenDevice' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XGetExtensionVersion' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XListInputDevices' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XSelectExtensionEvent' collect2: ld gab 1 als Ende-Status zur?ck make[3]: *** [dillo] Fehler 1 make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' make: *** [all] Fehler 2 Can you give me an advice? I don't know exactly where I should begin searching for advice.... Regards Michael -----Urspr?ngliche Nachricht----- Von: corvid [mailto:corvid@lavabit.com] Gesendet: Donnerstag, 13. August 2009 02:10 An: Heiser Michael Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin If you get it working from that document mentioned on the uclinux forum, let us know so that I can add to Compatibility.html :) Von AVG ?berpr?ft - www.avg.de Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: 08/12/09 18:12:00

Aug. 14, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > > Jorge wrote: > > > [...] > > > All of these should be working now. Please report any further > > > problem you find. I'll try to make the empty cache entries removal > > > now, and then look for a way to hook the concurrent connection limit > > > without memory leaks. > > > > I don't know whether it's a problem, but I just noticed > > a difference in behaviour in that my form testcase that > > submits to localhost (there's no server listening) > > only prints "submitting multipart/form-data!" and > > I have to press stop to get > > '** WARNING **: IO_write, closing with pending data not sent' > > and see the query. > > Yes, I'm yet to look into it. > > BTW, just committed a patch for an elusive bug. Now it's > possible to browse (& populate DNS cache), disconnect, click a > link, have the abort operation on no network condition, reconnect > and click it again (and it will work!). > > The only bit missing is how to make the link return to its > normal color. a_Nav_repush() can do it easily but looks like an > overkill. Maybe Johannes has a good idea on this? Not sure why it should change it's color. It's still a visited link after all. Or does the link color have another semantics (like page is in cache) in dillo? Anyway, the real solution would need the DOM-tree which is currently not available. The DOM-tree would also be needed for :hover, :active, and for Javascript. However we could add a hack similar to the one to compute html->visited_color in Html_tag_open_body(). It assumes that there is just one visited_color in the whole page. Cheers, Johannes

Aug. 13, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > Jorge wrote: > > [...] > > All of these should be working now. Please report any further > > problem you find. I'll try to make the empty cache entries removal > > now, and then look for a way to hook the concurrent connection limit > > without memory leaks. > > I don't know whether it's a problem, but I just noticed > a difference in behaviour in that my form testcase that > submits to localhost (there's no server listening) > only prints "submitting multipart/form-data!" and > I have to press stop to get > '** WARNING **: IO_write, closing with pending data not sent' > and see the query. Yes, I'm yet to look into it. BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!). The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this? -- Cheers Jorge.-

Aug. 13, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > I added a new function call to the CCC API (wrapping the trick > of the previous patch) and used it in three parts of the code. > Please check the tip. > > > If I'm not connected and I try to go to a host that > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > Another SEGFAULT path was: > load dillo home > disconnect Internet > click 9years > press stop > > All of these should be working now. Please report any further > problem you find. I'll try to make the empty cache entries removal > now, and then look for a way to hook the concurrent connection limit > without memory leaks. I just got a segfault on NULL Info when going to the https url for the uclinux page: #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x83e5ab0, Data2=0x0) at capi.c:522 #2 0x08063028 in Capi_conn_resume () at capi.c:172 #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, Data1=0x0, Data2=0x8122730) at capi.c:577 #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, Data2=0x8122730) at chain.c:113 #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, Data1=0x8b8d260, Data2=0x0) at dpi.c:625 #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, Data2=0x0) at chain.c:136 #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, cmd=0x8ee2400 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F…' query='GET /gf/project/uclinux-dist/fo"..., server=0x8b8d260 "proto.https", flags=1) at capi.c:482 [snip]

Aug. 13, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

Hi guys, Currently I'm searching for a small footprint webbrowser to use on my blackin device. This device is driven by uClinux. The first positive I can tell you is, that I compiled fltk2 for blackfin with success. I followed the instructions on tw.myblog.yahoo.com/stevegigijoe/article<http://tw.myblog.yahoo.com/stevegigijoe/article?mid=138&prev=-1&next=137> to compile and run fltk2. My modifications can be read at https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F… So now I'm facing a problem with the configure script of dillo. I had to make few changes to configure.in to recognize crosscompiled Fltk2 lib. These changes went ok but when configure checks libz, then it crashes because it can't find right version of the library. So my question is, how can I tell configure to search in my uClinux directory where the library already is persistent for use with uClinux. Best Regards from Germany, Michae

Aug. 12, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > I added a new function call to the CCC API (wrapping the trick > of the previous patch) and used it in three parts of the code. > Please check the tip. > > > If I'm not connected and I try to go to a host that > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > Another SEGFAULT path was: > load dillo home > disconnect Internet > click 9years > press stop > > All of these should be working now. Please report any further > problem you find. I'll try to make the empty cache entries removal > now, and then look for a way to hook the concurrent connection limit > without memory leaks. I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.

Aug. 10, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > whole chain in one single step (for simplicity) and to > > > > > define a standard way to end/abort the CCC (which I've > > > > > given some thought). If muses decide to pay me a visit, > > > > > I may develop a patch for this soon. :-) > > > > > > > > Good news. > > > > > > > > I already have dillo running on CCCs that build in one step > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > quite stable and behaves very well. Now I have to think what to > > > > do with the gained simplicity. :) > > > > > > Something isn't working right in the new code for Abort. > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > fails to resolve, I get a segfault. > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > ** WARNING **: CCC: call on already finished chain.) > > > > > [...] > > > Now after dns resolution times out, retrying in a new window/tab > > > doesn't seem to work. > > > > Please try the current tip. It's not definitive, but it looks > > like with some API polish it may be. > > Oh, there still is a bug after all. Yes, it's the same bug BTW. I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip. > If I'm not connected and I try to go to a host that > I have listed in /etc/hosts, then ^Q gives me a segfault. Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks. -- Cheers Jorge.-

Aug. 8, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > whole chain in one single step (for simplicity) and to > > > > define a standard way to end/abort the CCC (which I've > > > > given some thought). If muses decide to pay me a visit, > > > > I may develop a patch for this soon. :-) > > > > > > Good news. > > > > > > I already have dillo running on CCCs that build in one step > > > (both for HTTP and DPI), and also updated the documentation. It's > > > quite stable and behaves very well. Now I have to think what to > > > do with the gained simplicity. :) > > > > Something isn't working right in the new code for Abort. > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > fails to resolve, I get a segfault. > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > ** WARNING **: CCC: call on already finished chain.) > > > [...] > > Now after dns resolution times out, retrying in a new window/tab > > doesn't seem to work. > > Please try the current tip. It's not definitive, but it looks > like with some API polish it may be. Oh, there still is a bug after all. If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.

Aug. 7, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) > [...] > Now after dns resolution times out, retrying in a new window/tab > doesn't seem to work. Please try the current tip. It's not definitive, but it looks like with some API polish it may be. -- Cheers Jorge.-

Aug. 7, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) Good! This will hopefully help me clean some old ad-hoc bindings. A simple way to avoid the segfault is to comment the line at http.c:497 (i.e. leave it as it was). Now, my idea is to standardize OpAbort, and have a uniform way to call it and thus avoid ad-hoc calls/non-calls that nobody understands. This may take some time or just a bit (we'll see..). The plan is to include the empty-cache-entry removal feature and improve OpStop once things are uniform. Stay tuned... -- Cheers Jorge.-

Aug. 6, 2009