- Dillo-dev - lists.mailman3.com

Dillo 0.7.2 with IPv6 - cross-compiling for iPAQ H3970
by Ruth Vázquez Cerro July 18, 2003

July 18, 2003

Hello, I'd like to use dillo with IPv6 in my H3970 iPAQ. I have the cross-compiling environment but it lacks of some libs and header source files that make dillo impossible to ./configure and hence to compile. Can anyone tell me where do I get those librarys from? The lines that worry me are copied here. Below the output of configure is copied too. [...] checking zlib.h usability... no checking zlib.h presence... no checking for zlib.h... no configure: WARNING: *** No libz found. *** checking jpeglib.h usability... no checking jpeglib.h presence... no checking for jpeglib.h... no configure: WARNING: *** No libjpeg found. Disabling jpeg images.*** which: no libpng-config in (/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/prueba/bin:/usr/sbin/:/usr/local/arm/3.2.3/bin/) which: no libpng12-config in (/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/prueba/bin:/usr/sbin/:/usr/local/arm/3.2.3/bin/) checking png.h usability... no checking png.h presence... no checking for png.h... no checking libpng/png.h usability... no checking libpng/png.h presence... no checking for libpng/png.h... no configure: WARNING: *** No libpng found. Disabling png images.*** checking for pthread_create in -lpthread... no [...] checking for socket... no [...] ---------------------------------------------------- output of configure: $ ./configure -n --host=arm-linux configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking build system type... i686-pc-linux-gnu checking host system type... arm-unknown-linux-gnu checking target system type... arm-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for arm-linux-strip... arm-linux-strip checking for arm-linux-gcc... arm-linux-gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-linux-gcc accepts -g... yes checking for arm-linux-gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of arm-linux-gcc... gcc3 checking for arm-linux-gcc option to accept ANSI C... none needed checking for arm-linux-ranlib... arm-linux-ranlib checking how to run the C preprocessor... arm-linux-gcc -E checking for gtk-config... /usr/bin/gtk-config checking for GTK - version >= 1.2.0... cross compiling; assumed OK... yes checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking zlib.h usability... no checking zlib.h presence... no checking for zlib.h... no configure: WARNING: *** No libz found. *** checking jpeglib.h usability... no checking jpeglib.h presence... no checking for jpeglib.h... no configure: WARNING: *** No libjpeg found. Disabling jpeg images.*** which: no libpng-config in (/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/prueba/bin:/usr/sbin/:/usr/local/arm/3.2.3/bin/) which: no libpng12-config in (/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/prueba/bin:/usr/sbin/:/usr/local/arm/3.2.3/bin/) checking png.h usability... no checking png.h presence... no checking for png.h... no checking libpng/png.h usability... no checking libpng/png.h presence... no checking for libpng/png.h... no configure: WARNING: *** No libpng found. Disabling png images.*** checking for pthread_create in -lpthread... no checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking for socket... no configure: creating ./config.status Thanks in advance for your help. Ruth. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ruth Vázquez Cerro Telefónica Investigación y Desarrollo, S.A. Tecnologías de acceso a Redes IP C/ Emilio Vargas, nº6. - 28043 Madrid - Tlf: (+34) 913371119 e-mail: rvc(a)tid.es ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Dillo 0.7.3 delayed...
by Jorge Arellano Cid July 17, 2003

July 17, 2003

Hi guys! Did you test 0.7.3 as I suggested? The good/bad news (depends on being optimistic/pesimistic!) is that yesterday I found a bug. The newest CVS has a g_print that makes it evident. Valgrind says: ==983== Invalid memory access of size 1 ==983== at 0x4014861B: strcmp (in /usr/local/lib/valgrind/valgrind.so) ==983== by 0x403CABAD: g_str_equal (in /usr/lib/libglib-1.2.so.0.0.10) ==983== by 0x403BDB38: g_hash_table_lookup_extended (in /usr/lib/libglib-1.2 ==983== by 0x805B912: p_Dw_gtk_viewport_put_anchor (dw_gtk_viewport.c:770) ==983== Address 0x41054960 is 0 bytes inside a block of size 12 free'd ==983== at 0x40148050: free (in /usr/local/lib/valgrind/valgrind.so) ==983== by 0x403C1FE8: g_free (in /usr/lib/libglib-1.2.so.0.0.10) ==983== by 0x805D646: Dw_page_destroy (dw_page.c:338) ==983== by 0x402EB876: gtk_marshal_NONE__NONE (in /usr/lib/libgtk-1.2.so.0.9 Note the p_Dw_gtk_viewport_put_anchor where the g_print is. This may come from somewhere else, so let's hunt. It should be solved before making the release. Cheers Jorge.-

2 3

Re: [Dillo-dev] dillo size is 1.2mb ?
by Jorge Arellano Cid July 17, 2003

July 17, 2003

Nagaraja, > Hi Jorge, > > Thank you very much for your reply. > Actually I thought of upgrading my gtk from 1.2.7 -to 1.2.10 that is > why i took some time get back to you. > Now i am using glib-1.2.10 and gtk-1.2.10. even now I am getting the > same sime i.e 2+mb before strip and 1+mb aafter strip. > > and here is the result of ldd dillo: > libjpeg.so.62 => /opt/toolchain/arm-linux/lib/libjpeg.so.62 (0x40020000) > libpng.so.2 => /opt/toolchain/arm-linux/lib/libpng.so.2 (0x40047000) > libpthread.so.0 => /lib/libpthread.so.0 (0x40069000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40086000) > libdl.so.2 => /lib/libdl.so.2 (0x400c7000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400d2000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400e6000) > libm.so.6 => /lib/libm.so.6 (0x40198000) > libc.so.6 => /lib/libc.so.6 (0x401c6000) > libz.so.1 => /usr/lib/libz.so.1 (0x402de000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x402f6000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40301000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > so no where I can find gtk-1.2.so.0 and other libraries. That's a very interesting point. In my machine, I get: libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40070000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009a000) libz.so.1 => /usr/lib/libz.so.1 (0x400b7000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c4000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e2000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40213000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40217000) libdl.so.2 => /lib/libdl.so.2 (0x40238000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023b000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40249000) libm.so.6 => /lib/libm.so.6 (0x40310000) libc.so.6 => /lib/libc.so.6 (0x40333000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) gtk is in there! Make sure there's a libgtk-1.2.so.0, or similar, in your system (not just the static ".a"). > I am using armnative compiler which I built with binutils-2.13.2.1 > ,gcc-2.95.3 with idsn patch and glibc-2.2.2 > on our custom made board(strongarm-sa1110),and is working fine. OK. > I am using 32-bit machine here is the output of file: > dillo: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, > dynamically linked (uses shared libs), stripped > > Could you please mail me what is going wrong,is there any way by which I > can force dillo to compile every thing dynamically. Make sure there's the .so, and Try again. If it fails, try renaming the .a and see what the compiler (or linker) says. Continue from there. Ah!, and please write back to the mailing list. There're plenty of people with assorted knowledge there. Last hint: gtk should be shown from `ldconfig -p`. Cheers Jorge.- > Jorge Arellano Cid wrote: > > >Nagaraja wrote: > > > > > > > >>Hi All, > >> > >> > > > > Hi. > > > > > > > >>I got dillo compiled on arm with natively build toolchain, when I > >>check the size of dillo it is 1.2mb. > >> > >>my configure option is: > >> > >>./configure --with-gtk-prefix=/etc/gtk --x-includes=/usr/X11R6/include > >>--x-libraries=/opt/toolchain/arm-linux/lib/X11 > >>--with-jpeg-lib=/opt/toolchain/arm-linux/lib > >> > >>when I do file dillo ....... I am getting. > >>dillo: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, > >>dynamically linked (uses shared libs), stripped > >> > >>nothing seems satically linked. > >> > >> > > > > :( > > > > Well, please assert not a single library was linked in statically. > >Maybe `strings dillo` or better `nm dillo` could help. > > > > (IO/libDio.a is OK to be included statically! ;) > > > > > > > >>could any one please tell me what could be the cause..... > >> > >> > > > > A long time ago I was getting huge binaries for dillo with lcc, > >I don't know which compiler you're using, but it can be an issue. > >(On 64bit machines it also grows somehow). Please tell us what > >you find out. > > > > > > Cheers > > Jorge.- > > > > > >_______________________________________________ > >Dillo-dev mailing list > >Dillo-dev(a)lists.auriga.wearlab.de > >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > > > > > > >

1 0

Re: [Dillo-dev] Dillo 0.7.3 delayed...
by Jorge Arellano Cid July 16, 2003

July 16, 2003

On Wed, 16 Jul 2003, Sebastian Geerken wrote: > > On Wed, 9 Jul 2003, Jorge Arellano Cid wrote: > > > > > [...] > > > The good/bad news (depends on being optimistic/pesimistic!) is > > > that yesterday I found a bug. The newest CVS has a g_print that > > > makes it evident. > > > > I digged in a bit more and found the bug! Just a missing > > "break;" inside a case. The patch is in CVS. > > > > In any case, I'll wait for Sebastian to confirm me that. At > > first I hesitated because 5 anchors in the splash page produced > > about 15 extra calls, but this seems OK because they need to > > update the offset as the text rewraps. > > This seems correct, but I haven't yet examine it in detail. Anyway, > current CVS has this g_print line commented. OK. > AFAIS, this would be the last issue delaying the release, what I see > else in the bug track: > > - 470: Is this the one which has been fixed? I just sent an email to fred for confirmation. > - 476: This is already older (tested with 0.7.1, which happened to > be available :-), so it is not something making dillo more > buggy than before. :) Ok guys, give our CVS code a hard test! If everything goes OK, that'd be 0.7.3. Cheers Jorge.-

1 0

BUG#471
by Jorge Arellano Cid July 16, 2003

July 16, 2003

Hi there, In BUG#471 (bad rendering for http://futurezone.orf.at) the problem is their html (extensive use of deprecated NOWRAP tag). sed 's/NOWRAP//g' solves the problem! Please tell the webmaster (they're usually responsive to HTML fault reports). Cheers Jorge.-

1 0

Selection segfault again
by Andrew A. Gill July 16, 2003

July 16, 2003

[I'm not subscribed to this list, but I do regularly check the archives. Lets see if this gets through.] Sebastian Geerken: > > Something I forgot: The fix does not work perfectly, when, in the test > page, you start select within the text, and then move the pointer > below the text, the selection starts at the beginning. This is a known > bug, and it won't be fixed for 0.7.3. If you're referring to what I think you're referring to, I prefer to think of that as a feature. Well, now that I test it, it looks like a different feature. Go to: <http://www.planetnintendo.com/ff1/> Friggin' black-text-on-black-background! Select within the text and drag the cursor to the lower right corner of the screen. Voila! All the text within the page is selected! Now you can read it without changing the dillorc! Which reminds me--maybe there should be a way to change page layout per page. -- |Andrew A. Gill |<superluser(a)frontiernet.net>

3 2

Re: [Dillo-dev] dillo size is 1.2mb ?
by Jorge Arellano Cid July 15, 2003

July 15, 2003

Nagaraja wrote: > Hi All, Hi. > I got dillo compiled on arm with natively build toolchain, when I > check the size of dillo it is 1.2mb. > > my configure option is: > > ./configure --with-gtk-prefix=/etc/gtk --x-includes=/usr/X11R6/include > --x-libraries=/opt/toolchain/arm-linux/lib/X11 > --with-jpeg-lib=/opt/toolchain/arm-linux/lib > > when I do file dillo ....... I am getting. > dillo: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, > dynamically linked (uses shared libs), stripped > > nothing seems satically linked. :( Well, please assert not a single library was linked in statically. Maybe `strings dillo` or better `nm dillo` could help. (IO/libDio.a is OK to be included statically! ;) > could any one please tell me what could be the cause..... A long time ago I was getting huge binaries for dillo with lcc, I don't know which compiler you're using, but it can be an issue. (On 64bit machines it also grows somehow). Please tell us what you find out. Cheers Jorge.-

1 0

dillo size is 1.2mb ?
by Nagaraja July 14, 2003

July 14, 2003

Hi All, I got dillo compiled on arm with natively build toolchain, when I check the size of dillo it is 1.2mb. my configure option is: ./configure --with-gtk-prefix=/etc/gtk --x-includes=/usr/X11R6/include --x-libraries=/opt/toolchain/arm-linux/lib/X11 --with-jpeg-lib=/opt/toolchain/arm-linux/lib when I do file dillo ....... I am getting. dillo: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, dynamically linked (uses shared libs), stripped nothing seems satically linked. could any one please tell me what could be the cause..... Thanks and regards Nags

2 1

Some news...
by Jorge Arellano Cid July 14, 2003

July 14, 2003

Hi there! This has been a very busy week. I didn't anticipate how much work the dpid (dpi daemon) integration could take. Don't panic though!, the code that binds it all is running (to some extent) in my machine. The time consuming problem is that while making the integration, a lot of design matters spring in, and they take a lot of time to solve. The good news is that it all starts to shape into a more clear design (the code is still hackish at parts, but it is clear what, where and how to fix it). While working the gory details of it, I realized it'd be a good idea to make the 0.7.3 release with what we have now (plus a little bug fix we're working on with Sebastian). That way, there'll be less pressure on us while polishing the new dpid implementation, and hey!, it's been a long time since our last release. I'll keep the CVS free of the dpid code until the 0.7.3 release is done. For the meanwhile, I'll provide a tarball to the new code. (and if I can't wrap the new code before Monday, I'll provide a link to the latest dpid testing tarball I have). Cheers Jorge.-

5 5

*** Lowest Rate Mortgages - Personal Service *** vmigiij r
by w2E1R786gI＠process4unow.com July 14, 2003

July 14, 2003

1 0