-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey@all :) I ran into some issues compiling dillo. I solved / worked around them, patches are attached. Here are my findings and my interpretations (let me know in case I am way off somewhere): dw2 === gcc-4.2 on linux/x86_64 complained about two casts in lout/object.cc: object.cc:118: error: cast from ?void*? to ?int? loses precision I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P. dillo2 ====== There was another complaint by gcc: dialog.cc:249: error: cast from ?void*? to ?int? loses precision A parameter of type void* for a callback is used to carry a small integer (most likely the number of the button pressed or something). I solved this one by first casting to long and then to int. I saw this somewhere on the net, don't know if this is too hacky. dillo2/dpi ========== downloads.cc failed to compile since gcc couldn't find the fltk includes (I chose not to install them to /usr/local/lib), so I poked around in dpi/Makefile.am and managed to include LIBFLTK_CXXFLAGS into cxxflags (/me is an automake n00b). With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here? Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID6/ToPmwNWhsaZYRApgwAJsENlC0vsniya14RBTU8yrXVVjVyACff2HD GLM/iKxXf3UjBA6+GFOSE78= =JuDE -----END PGP SIGNATURE-----
On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote:
dialog.cc:249: error: cast from ?void*? to ?int? loses precision
A parameter of type void* for a callback is used to carry a small integer (most likely the number of the button pressed or something). I solved this one by first casting to long and then to int. I saw this somewhere on the net, don't know if this is too hacky.
Please cast to (u)intptr_t instead. Joerg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joerg Sonnenberger wrote:
On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote:
[...] somewhere on the net, don't know if this is too hacky. Please cast to (u)intptr_t instead. Like this?
Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID7bfoPmwNWhsaZYRAuaeAJ4q16SFUnUIVnPhJlczP9Dft6WW1gCaA8+T ZoqvRZq/4X4Qoxjw/UrMuA0= =SxsP -----END PGP SIGNATURE-----
[it seems like everybody on this list has a name starting with J] Justus wrote:
With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here?
Was dillo unable to find dpid, or was it just not working right somehow? Looking in dillo2/src/IO/dpi.c, dpid has to be either in ~/.dillo/ or $PATH. I put it in my path.
Hi Justus, On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey@all :)
I ran into some issues compiling dillo. I solved / worked around them, patches are attached. Here are my findings and my interpretations (let me know in case I am way off somewhere):
dw2 === gcc-4.2 on linux/x86_64 complained about two casts in lout/object.cc:
object.cc:118: error: cast from ?void*? to ?int? loses precision
I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P.
I think the idea is that the compiler will optimize out unnecessary branches. And indeed the assembly code looks like this here: .globl _ZN6object7Pointer9hashValueEv .type _ZN6object7Pointer9hashValueEv, @function _ZN6object7Pointer9hashValueEv: .LFB70: .loc 1 115 0 .LVL1: pushl %ebp .LCFI2: movl %esp, %ebp .LCFI3: .loc 1 115 0 movl 8(%ebp), %eax movl 4(%eax), %eax .loc 1 126 0 leave ret .LFE70: .size _ZN6object7Pointer9hashValueEv, .-_ZN6object7Pointer9hashValueEv So, as far as I can see it really works. Cheers, Johannes
dillo2 ====== There was another complaint by gcc:
dialog.cc:249: error: cast from ?void*? to ?int? loses precision
A parameter of type void* for a callback is used to carry a small integer (most likely the number of the button pressed or something). I solved this one by first casting to long and then to int. I saw this somewhere on the net, don't know if this is too hacky.
dillo2/dpi ========== downloads.cc failed to compile since gcc couldn't find the fltk includes (I chose not to install them to /usr/local/lib), so I poked around in dpi/Makefile.am and managed to include LIBFLTK_CXXFLAGS into cxxflags (/me is an automake n00b).
With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here?
Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFID6/ToPmwNWhsaZYRApgwAJsENlC0vsniya14RBTU8yrXVVjVyACff2HD GLM/iKxXf3UjBA6+GFOSE78= =JuDE -----END PGP SIGNATURE-----
diff -pru dw2/lout/object.cc dw2-cur/lout/object.cc --- dw2/lout/object.cc 2007-10-26 14:17:43.000000000 +0200 +++ dw2-cur/lout/object.cc 2008-04-23 23:13:31.000000000 +0200 @@ -114,28 +114,21 @@ bool Pointer::equals(Object *other)
int Pointer::hashValue() { - if(sizeof (int) == sizeof (void*)) - return (int)value; - else if (2 * sizeof (int) == sizeof (void*)) - return ((int*)value)[0] ^ ((int*)value)[1]; - else { - // unhandled case - misc::assertNotReached (); - return 0; - } +#if SIZEOF_VOID_P == 4 + return (int)value; +#else + return ((int*)value)[0] ^ ((int*)value)[1]; +#endif }
void Pointer::intoStringBuffer(misc::StringBuffer *sb) { char buf[64]; - if(sizeof (int) == sizeof (void*)) - sprintf(buf, "0x%x", (int)value); - else if (sizeof (long) == sizeof (void*)) - sprintf(buf, "0x%lx", (long)value); - else { - // unhandled case - misc::assertNotReached (); - } +#if SIZEOF_VOID_P == 4 + sprintf(buf, "0x%x", (int)value); +#else + sprintf(buf, "0x%lx", (long)value); +#endif sb->append(buf); }
diff -pru dillo2/src/dialog.cc dillo2-cur/src/dialog.cc --- dillo2/src/dialog.cc 2008-04-11 14:51:24.000000000 +0200 +++ dillo2-cur/src/dialog.cc 2008-04-23 22:38:50.000000000 +0200 @@ -246,7 +246,7 @@ static int choice5_answer;
void choice5_cb(Widget *button, void *number) { - choice5_answer = (int)number; + choice5_answer = (int)(long)number; _MSG("choice5_cb: %d\n", choice5_answer); button->window()->make_exec_return(true); }
diff -pru dillo2/dpi/Makefile.am dillo2-cur/dpi/Makefile.am --- dillo2/dpi/Makefile.am 2007-10-07 00:36:34.000000000 +0200 +++ dillo2-cur/dpi/Makefile.am 2008-04-23 22:53:32.000000000 +0200 @@ -1,3 +1,5 @@ +AM_CXXFLAGS = @LIBFLTK_CXXFLAGS@ + bookmarksdir = $(libdir)/dillo/dpi/bookmarks downloadsdir = $(libdir)/dillo/dpi/downloads ftpdir = $(libdir)/dillo/dpi/ftp
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote:
object.cc:118: error: cast from ?void*? to ?int? loses precision
I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P.
I think the idea is that the compiler will optimize out unnecessary branches. And indeed the assembly code looks like this here:
Ah, I see. But surely I can't be the only one having problems with this code? $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v - --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr - --enable-shared --with-system-zlib --libexecdir=/usr/lib - --without-included-gettext --enable-threads=posix --enable-nls - --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 - --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc - --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu - --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $ uname -a Linux thinkbox 2.6.24-15-generic #1 SMP Mon Apr 7 16:37:53 UTC 2008 x86_64 GNU/Linux And I would guess my compiler bails out at parsing the code and building an syntax tree way before it has a chance to optimize out any branches. Maybe your compiler is more permissive, either because it's a different version or you're on a different architecture where sizeof(int) == sizeof(void*) so there isn't any "loss of precision"? Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEZxCoPmwNWhsaZYRAhYmAJ4zATWlJpwFzwLlI0I3joMtmY1AOgCgmSWg /j07wxgS2ppgaV5swTCRubI= =MFTB -----END PGP SIGNATURE-----
On Fri, Apr 25, 2008 at 10:54:26AM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johannes Hofmann wrote:
object.cc:118: error: cast from ?void*? to ?int? loses precision
I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P.
I think the idea is that the compiler will optimize out unnecessary branches. And indeed the assembly code looks like this here:
Ah, I see. But surely I can't be the only one having problems with this code?
$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v - --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr - --enable-shared --with-system-zlib --libexecdir=/usr/lib - --without-included-gettext --enable-threads=posix --enable-nls - --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 - --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc - --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu - --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $ uname -a Linux thinkbox 2.6.24-15-generic #1 SMP Mon Apr 7 16:37:53 UTC 2008 x86_64 GNU/Linux
And I would guess my compiler bails out at parsing the code and building an syntax tree way before it has a chance to optimize out any branches. Maybe your compiler is more permissive, either because it's a different version or you're on a different architecture where sizeof(int) == sizeof(void*) so there isn't any "loss of precision"?
You seem to be the first one to try to compile dillo2 with 64bit. So yes, we need to fix that compilation problem. It's just that currently there is hardly any conditional compilation in dw-testbed and it would be nice to keep it that way. Do you think you can fix the problem without any preprocessor conditionals? Perhaps with some sort of cast as in the callback case. Johannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote:
You seem to be the first one to try to compile dillo2 with 64bit. So yes, we need to fix that compilation problem. It's just that currently there is hardly any conditional compilation in dw-testbed and it would be nice to keep it that way. Do you think you can fix the problem without any preprocessor conditionals? Perhaps with some sort of cast as in the callback case.
Ah, I see where you are heading. Patch is attached. I was just compiling dillo with my patches on a 32 bit machine just to check whether I broke anything and I noticed that make tried to build the https dpi despite the fact that the ssl.h header file was missing (and configure was checking for that). I would suggest to either complain about missing dependencies or to disable the compilation of the https dpi in case there is no ssl library found. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEgPnoPmwNWhsaZYRAm+nAKC4f9YHp2jwYjAhTwkh7uiX5Tie4wCfehOq OMZQ28n3I2R0u6eX+1V/f68= =2iR2 -----END PGP SIGNATURE-----
On Fri, Apr 25, 2008 at 06:16:40PM +0200, Justus Winter wrote:
diff -pru dw2/lout/object.cc dw2-cur/lout/object.cc --- dw2/lout/object.cc 2007-10-26 14:17:43.000000000 +0200 +++ dw2-cur/lout/object.cc 2008-04-25 17:20:56.000000000 +0200 @@ -22,6 +22,7 @@
#include "object.hh" #include <stdio.h> +#include <unistd.h> // for intptr_t
inttypes.h
void Pointer::intoStringBuffer(misc::StringBuffer *sb) { char buf[64]; - if(sizeof (int) == sizeof (void*)) - sprintf(buf, "0x%x", (int)value); - else if (sizeof (long) == sizeof (void*)) - sprintf(buf, "0x%lx", (long)value); - else { - // unhandled case - misc::assertNotReached (); - } + sprintf(buf, "0x%lx", (intptr_t)value);
snprintf(buf, sizeof(buf), "%p", value) if you don't care about the concrete representation, typically this is using hex as well. If you really do: snprintf(buf, sizeof(buf), "0x%zu", (size_t)value); Joerg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's hard to get anything past you guys... revised patches are attached. By the way, if you still think there's something wrong with them, please adjust them accordingly (like checking the return value of snprintf, reducing the size of buf (a 64 byte long char buffer should be enough for the hexadecimal representation of 244 bit wide pointers plus '0x' and the final 0, right? :) ). Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEh9ZoPmwNWhsaZYRAj50AJ9QWcxALBx1fuLIqEBAbNKsGn5PogCbBRRV QjvTVKQJnI1yzOamX2KwOy8= =TVic -----END PGP SIGNATURE-----
On Fri, Apr 25, 2008 at 08:13:45PM +0200, Justus Winter wrote:
By the way, if you still think there's something wrong with them, please adjust them accordingly (like checking the return value of snprintf, reducing the size of buf (a 64 byte long char buffer should be enough for the hexadecimal representation of 244 bit wide pointers plus '0x' and the final 0, right? :) ).
I am just a bystander myself :-) "%p" really is enough (includes 0x). snprintf because it doesn't match static scans for potentially unsafe functions. Joerg
On Fri, Apr 25, 2008 at 08:13:45PM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
It's hard to get anything past you guys... revised patches are attached.
By the way, if you still think there's something wrong with them, please adjust them accordingly (like checking the return value of snprintf, reducing the size of buf (a 64 byte long char buffer should be enough for the hexadecimal representation of 244 bit wide pointers plus '0x' and the final 0, right? :) ).
Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIEh9ZoPmwNWhsaZYRAj50AJ9QWcxALBx1fuLIqEBAbNKsGn5PogCbBRRV QjvTVKQJnI1yzOamX2KwOy8= =TVic -----END PGP SIGNATURE-----
diff -pru dillo2/src/dialog.cc dillo2-cur/src/dialog.cc --- dillo2/src/dialog.cc 2008-04-11 14:51:24.000000000 +0200 +++ dillo2-cur/src/dialog.cc 2008-04-24 00:19:39.000000000 +0200 @@ -11,6 +11,7 @@
// UI dialogs
+#include <inttypes.h> #include <math.h> // for rint()
#include <fltk/events.h> // for the unfortunate (temporary?) event key testing @@ -246,7 +247,7 @@ static int choice5_answer;
void choice5_cb(Widget *button, void *number) { - choice5_answer = (int)number; + choice5_answer = (intptr_t)number; _MSG("choice5_cb: %d\n", choice5_answer); button->window()->make_exec_return(true); }
diff -pru dw2/lout/object.cc dw2-cur/lout/object.cc --- dw2/lout/object.cc 2007-10-26 14:17:43.000000000 +0200 +++ dw2-cur/lout/object.cc 2008-04-25 19:01:34.000000000 +0200 @@ -22,6 +22,7 @@
#include "object.hh" #include <stdio.h> +#include <inttypes.h>
namespace object {
@@ -114,28 +115,13 @@ bool Pointer::equals(Object *other)
int Pointer::hashValue() { - if(sizeof (int) == sizeof (void*)) - return (int)value; - else if (2 * sizeof (int) == sizeof (void*)) - return ((int*)value)[0] ^ ((int*)value)[1]; - else { - // unhandled case - misc::assertNotReached (); - return 0; - } + return (intptr_t)value; }
The xor-stuff in the 64bit case ensures a equal distribution of hash values. I'm not sure a simple cast to int is enough on all systems (well, it probabely is..). intptr_t v = (intptr_t) value; return (int) v ^ (v >> (sizeof int * 8)); for the 64bit case would be a more conservative fix - if it compiles :-)
void Pointer::intoStringBuffer(misc::StringBuffer *sb) { char buf[64]; - if(sizeof (int) == sizeof (void*)) - sprintf(buf, "0x%x", (int)value); - else if (sizeof (long) == sizeof (void*)) - sprintf(buf, "0x%lx", (long)value); - else { - // unhandled case - misc::assertNotReached (); - } + snprintf(buf, sizeof(buf), "0x%p", value); sb->append(buf); }
Nice simplification! Johannes
On Fri, Apr 25, 2008 at 04:38:09PM +0200, Johannes Hofmann wrote:
On Fri, Apr 25, 2008 at 10:54:26AM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johannes Hofmann wrote:
object.cc:118: error: cast from ?void*? to ?int? loses precision
I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P.
I think the idea is that the compiler will optimize out unnecessary branches. And indeed the assembly code looks like this here:
Ah, I see. But surely I can't be the only one having problems with this code?
$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v - --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr - --enable-shared --with-system-zlib --libexecdir=/usr/lib - --without-included-gettext --enable-threads=posix --enable-nls - --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 - --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc - --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu - --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $ uname -a Linux thinkbox 2.6.24-15-generic #1 SMP Mon Apr 7 16:37:53 UTC 2008 x86_64 GNU/Linux
And I would guess my compiler bails out at parsing the code and building an syntax tree way before it has a chance to optimize out any branches. Maybe your compiler is more permissive, either because it's a different version or you're on a different architecture where sizeof(int) == sizeof(void*) so there isn't any "loss of precision"?
You seem to be the first one to try to compile dillo2 with 64bit. So yes, we need to fix that compilation problem. It's just that currently there is hardly any conditional compilation in dw-testbed and it would be nice to keep it that way. Do you think you can fix the problem without any preprocessor conditionals? Perhaps with some sort of cast as in the callback case.
Yes, that's right. Doesn't dlib's VOIDP2INT() work in this case? -- Cheers Jorge.- PS: Sorry for the lack of presence lately. I've been fully busy.
Hi Justus,
It's hard to get anything past you guys... revised patches are attached.
:-) No, you just had bad luck. 64bit is a complex matter that looks simple. BTW, I'm quite happy that a few patches made dillo2 run on 64bit. On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey@all :)
I ran into some issues compiling dillo. I solved / worked around them, patches are attached. Here are my findings and my interpretations (let me know in case I am way off somewhere):
dw2 === gcc-4.2 on linux/x86_64 complained about two casts in lout/object.cc:
object.cc:118: error: cast from ???void*??? to ???int??? loses precision
I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P.
After reviewing the thread, and a head scratching phase, I committed the following code. please test it: +/* For some unknown reason, this doesn't compile on some 64bit platforms: + * + * if (sizeof (int) == sizeof (void*)) + * return (int)value; + * else + * return ((int*)value)[0] ^ ((int*)value)[1]; + */ +#if SIZEOF_VOID_P == 4 + return (int)value; +#else + return ((int*)value)[0] ^ ((int*)value)[1]; +#endif
dillo2 ====== There was another complaint by gcc:
dialog.cc:249: error: cast from ???void*??? to ???int??? loses precision
A parameter of type void* for a callback is used to carry a small integer (most likely the number of the button pressed or something). I solved this one by first casting to long and then to int. I saw this somewhere on the net, don't know if this is too hacky.
Committed as: + choice5_answer = VOIDP2INT(number);
dillo2/dpi ========== downloads.cc failed to compile since gcc couldn't find the fltk includes (I chose not to install them to /usr/local/lib), so I poked around in dpi/Makefile.am and managed to include LIBFLTK_CXXFLAGS into cxxflags (/me is an automake n00b).
Yeah, auto* is not simple. Does it work for you with a: +downloads_dpi_CXXFLAGS = @LIBFLTK_CXXFLAGS@ instead? (CVS has this tentative patch).
With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here?
No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! (as we all run dillo1 before, ~/.dillo was there :-) dpid didn't start because it most probably wasn't in your path. With regard to a missing SSL, yes, it'd be good not to try to compile https the. Patches are welcomed! :-) -- Cheers Jorge.-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote:
After reviewing the thread, and a head scratching phase, I committed the following code. please test it:
+/* For some unknown reason, this doesn't compile on some 64bit platforms: + * + * if (sizeof (int) == sizeof (void*)) + * return (int)value; + * else + * return ((int*)value)[0] ^ ((int*)value)[1]; + */ +#if SIZEOF_VOID_P == 4 + return (int)value; +#else + return ((int*)value)[0] ^ ((int*)value)[1]; +#endif Works like a charm :)
+ choice5_answer = VOIDP2INT(number); dito. Dillo2 builds out of the box on linux/x86_64. Nice work everyone :)
Does it work for you with a:
+downloads_dpi_CXXFLAGS = @LIBFLTK_CXXFLAGS@ It does.
With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here? No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! (as we all run dillo1 before, ~/.dillo was there :-) dpid didn't start because it most probably wasn't in your path. Yes, that was indeed the problem.
Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE9quoPmwNWhsaZYRAqiwAJ9SMrcSOeK0TThwYnXVJq3xd+EHgQCggVtu 99J/iZXynpKWOYEwhBBAqPU= =SFEG -----END PGP SIGNATURE-----
Hi On Sun, Apr 27, 2008 at 03:46:11AM +0200, Justus Winter wrote:
[...]
With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here? No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! (as we all run dillo1 before, ~/.dillo was there :-)
A patch for ~/.dillo creation was just committed. -- Cheers Jorge.-
Jorge wrote:
On Wed, Apr 30, 2008 at 08:52:06PM +0000, corvid wrote:
Jorge wrote:
A patch for ~/.dillo creation was just committed.
I think dillo should tell the user that it is creating the directory.
Committed.
Shouldn't it be something like the following? (BTW, I had to set prefs.show_msg to get MSGs out of this and a_Prefs_init(), but setting it in dillo.cc doesn't feel like a good thing to do.)
On Fri, May 02, 2008 at 03:52:44PM +0000, corvid wrote:
Jorge wrote:
On Wed, Apr 30, 2008 at 08:52:06PM +0000, corvid wrote:
Jorge wrote:
A patch for ~/.dillo creation was just committed.
I think dillo should tell the user that it is creating the directory.
Committed.
Shouldn't it be something like the following?
(BTW, I had to set prefs.show_msg to get MSGs out of this and a_Prefs_init(), but setting it in dillo.cc doesn't feel like a good thing to do.)
Ooops, yes. Looks like I've had to little time lately. A fix was committed. Please check! :-) -- Cheers Jorge.-
participants (5)
-
4winter＠informatik.uni-hamburg.de -
corvid＠lavabit.com -
jcid＠dillo.org -
joerg.sonnenberger＠web.de -
Johannes.Hofmann＠gmx.de