Various minor patches
All, I am very glad to see that dillo-fltk has now gained some momentum. While looking at it on FreeBSD (6.2) I came across some minor problems, patches for which are attached: 1) detect_libiconv.diff src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am. 2) src-colors.h.diff I needed to include <stdint.h> or <inttypes.h> in order to have int32_t properly defined. I decided to wrap this include in a hopefully portable and correct way by instrumenting config.h. 3) src-dns.c.diff On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard. Otherwise dillo-fltk looks really promising -- keep up the good work! Best regards, -- Thomas-Martin Seck current dillo and FLTK port maintainer on FreeBSD
Hello, On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
All,
I am very glad to see that dillo-fltk has now gained some momentum.
While looking at it on FreeBSD (6.2) I came across some minor problems, patches for which are attached:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
2) src-colors.h.diff
I needed to include <stdint.h> or <inttypes.h> in order to have int32_t properly defined. I decided to wrap this include in a hopefully portable and correct way by instrumenting config.h.
3) src-dns.c.diff
On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard.
EAI_NODATA still exists on DragonFly. But if it's obsolete we should generally avoid to use it. Or to be on the safe side do something like: #ifdef EAI_NODATA ... #endif Regards, Johannes
Otherwise dillo-fltk looks really promising -- keep up the good work!
Best regards, -- Thomas-Martin Seck current dillo and FLTK port maintainer on FreeBSD
Content-Description: detect_libiconv.diff
--- dillo2/configure.in Fri Oct 19 17:39:27 2007 +++ dillo2-cur/configure.in Sun Jan 13 15:46:18 2008 @@ -300,6 +300,18 @@ AC_DEFINE([ENABLE_SSL], [], [Enable SSL support]) fi
+dnl ---------------------- +dnl Test for libiconv +dnl ---------------------- +AC_CHECK_HEADER(iconv.h, iconv_ok=yes, iconv_ok=no) +if test "x$iconv_ok" = "xyes"; then + AC_CHECK_LIB(iconv, iconv_open, iconv_ok=yes, iconv_ok=no) +fi +if test "x$iconv_ok" = "xyes"; then + LIBICONV_LIBS="-liconv" +else + AC_ERROR(libiconv must be installed!) +fi
dnl ---------------------- dnl Test for POSIX threads @@ -465,6 +477,7 @@ AC_SUBST(LIBFLTK_CXXFLAGS) AC_SUBST(LIBFLTK_CFLAGS) AC_SUBST(LIBFLTK_LIBS) +AC_SUBST(LIBICONV_LIBS) AC_SUBST(datadir) AC_SUBST(src doc)
--- dillo2/src/Makefile.am Tue Nov 13 14:56:43 2007 +++ dillo2-cur/src/Makefile.am Sun Jan 13 15:04:17 2008 @@ -14,7 +14,7 @@ ../../dw-testbed/dw/libDw-fltk.a \ ../../dw-testbed/dw/libDw-core.a \ ../../dw-testbed/lout/liblout.a \ - @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ + @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ @LIBICONV_LIBS@
dillo_fltk_SOURCES = \ dillo.cc \
Content-Description: src-colors.h.diff
--- dillo2/src/colors.h Sun Oct 7 00:36:34 2007 +++ dillo2-cur/src/colors.h Sun Jan 13 15:49:28 2008 @@ -1,6 +1,15 @@ #ifndef __COLORS_H__ #define __COLORS_H__
+#include "config.h" +#ifdef HAVE_INTTYPES_H +#include <inttypes.h> +#else +#ifdef HAVE_STDINT_H +#include <stdint.h> +#endif +#endif + #ifdef __cplusplus extern "C" { #endif /* __cplusplus */
Content-Description: src-dns.c.diff
--- dillo2/src/dns.c Mon Nov 5 21:25:16 2007 +++ dillo2-cur/src/dns.c Sun Jan 13 16:48:07 2008 @@ -289,8 +289,12 @@ static void *Dns_server(void *data) MSG("DNS error: HOST_NOT_FOUND\n"); else if (error == EAI_AGAIN) MSG("DNS error: TRY_AGAIN\n"); + /* The EAI_NODATA definition is marked as obsoleted in FreeBSD's netdb.h + * and is #if 0'ed in releases starting with 5.2: */ +#if !defined __FreeBSD__ || __FreeBSD__ <= 4 else if (error == EAI_NODATA) MSG("DNS error: NO_ADDRESS\n"); +#endif else if (h_errno == EAI_FAIL) MSG("DNS error: NO_RECOVERY\n"); } else {
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
* Johannes Hofmann (Johannes.Hofmann@gmx.de):
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
3) src-dns.c.diff
On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard.
EAI_NODATA still exists on DragonFly. But if it's obsolete we should generally avoid to use it. Or to be on the safe side do something like:
#ifdef EAI_NODATA ... #endif
Frankly, I do not know why certain constants were obsoleted over the years (in FreeBSD) -- it might be because some RFC/draft says so or ISC/Nominum decided to do so in their implementation which FreeBSD seems to track rather closely. DragonFly probably never felt the need to update this after importing the 4.something userland back in the day? One could make EAI_NODATA equal EAI_NONAME in this case, this is the way it was done in FreeBSD for a few months until 01/2004: <http://www.freebsd.org/cgi/cvsweb.cgi/src/include/netdb.h?rev=1.30;content-t...>. This is probably a better approach than the hard coded OS #ifdef I came up with first if one wants to catch this case at all.
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. I am using autoconf-2.61 and automake-1.9. Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log? Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly... Regards, Johannes
I am using autoconf-2.61 and automake-1.9.
Kind regards,
Christian
-- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS? -- Cheers Jorge.-
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't. This page seems to have good info: http://synflood.at/blog/index.php?/plugin/tag/bsd (my understanding of German is barely for survival. ;). -- Cheers Jorge.-
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:06]:
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't.
This page seems to have good info:
http://synflood.at/blog/index.php?/plugin/tag/bsd
(my understanding of German is barely for survival. ;).
Yes it does describe my problem, but how do we fix this in a portable way? -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:06]:
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't.
This page seems to have good info:
http://synflood.at/blog/index.php?/plugin/tag/bsd
(my understanding of German is barely for survival. ;).
Yes it does describe my problem, but how do we fix this in a portable way?
Before this patch, we had no test for iconv. Did it work for you then? -- Cheers Jorge.-
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:36]:
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:06]:
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't.
This page seems to have good info:
http://synflood.at/blog/index.php?/plugin/tag/bsd
(my understanding of German is barely for survival. ;).
Yes it does describe my problem, but how do we fix this in a portable way?
Before this patch, we had no test for iconv. Did it work for you then?
In a way yes. because my solution was to add -liconv to my LDFLAGS. Thanks for looking at this -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Wed, Jan 30, 2008 at 03:40:52PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:36]:
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:06]:
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't.
This page seems to have good info:
http://synflood.at/blog/index.php?/plugin/tag/bsd
(my understanding of German is barely for survival. ;).
Yes it does describe my problem, but how do we fix this in a portable way?
Before this patch, we had no test for iconv. Did it work for you then?
In a way yes. because my solution was to add -liconv to my LDFLAGS.
Did the new test in configure.in work? I assume not because of the silence. You wrote:
In a way yes. because my solution was to add -liconv to my LDFLAGS.
and
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
I assume you set LDFLAGS=-L/usr/local/lib... but this is expected to be done by the test at configure.in:96. The test can fail though! Would you mind posting the output of: cpp -v in your system. -- Cheers Jorge.-
* Jorge Arellano Cid <jcid@dillo.org> [080131 13:25]:
Before this patch, we had no test for iconv. Did it work for you then? In a way yes. because my solution was to add -liconv to my LDFLAGS.
Did the new test in configure.in work? Nope it did not.
You wrote:
In a way yes. because my solution was to add -liconv to my LDFLAGS. and This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
I assume you set LDFLAGS=-L/usr/local/lib...
but this is expected to be done by the test at configure.in:96. The test can fail though! Would you mind posting the output of:
cpp -v
in your system.
$ cpp -v Reading specs from /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/cc1 -E -traditional-cpp -quiet -nostdinc -v -I/usr/include -iprefix /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/ -D__GNUC__ - #include "..." search starts here: #include <...> search starts here: /usr/include End of search list. Hope this helps, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
On Thu, Jan 31, 2008 at 03:35:56PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080131 13:25]:
Before this patch, we had no test for iconv. Did it work for you then? In a way yes. because my solution was to add -liconv to my LDFLAGS.
Did the new test in configure.in work? Nope it did not.
You wrote:
In a way yes. because my solution was to add -liconv to my LDFLAGS. and This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
I assume you set LDFLAGS=-L/usr/local/lib...
but this is expected to be done by the test at configure.in:96. The test can fail though! Would you mind posting the output of:
cpp -v
in your system.
$ cpp -v Reading specs from /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/cc1 -E -traditional-cpp -quiet -nostdinc -v -I/usr/include -iprefix /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/ -D__GNUC__ - #include "..." search starts here: #include <...> search starts here: /usr/include End of search list.
Hope this helps,
OK, then configure.in:96 should be adding /usr/local/lib to LDFLAGS. If I understood correctly, the missing part is "-liconv" in LIBS. The CVS has new code for this. Please test, tweak and report back. Making a blind patch with auto*tools is not easy. -- Cheers Jorge.-
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:06]:
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't.
This page seems to have good info:
http://synflood.at/blog/index.php?/plugin/tag/bsd
(my understanding of German is barely for survival. ;).
Yes it does describe my problem, but how do we fix this in a portable way?
Not sure, it describes the same problem. I think the problem is that libiconv only exports libiconv_open() and the corresponding iconv.h header file defines iconv_open to libiconv_open. Unfortunately the test program generated by autoconf does not include iconv.h. Johannes
-- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Wed, Jan 30, 2008 at 04:37:09PM +0100, Johannes Hofmann wrote:
On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
* Jorge Arellano Cid <jcid@dillo.org> [080130 15:06]:
On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
Sorry, from the log it's clear it doesn't.
This page seems to have good info:
http://synflood.at/blog/index.php?/plugin/tag/bsd
(my understanding of German is barely for survival. ;).
Yes it does describe my problem, but how do we fix this in a portable way?
Not sure, it describes the same problem.
I think the problem is that libiconv only exports libiconv_open() and the corresponding iconv.h header file defines iconv_open to libiconv_open. Unfortunately the test program generated by autoconf does not include iconv.h.
OK, I modified configure.in in CVS. This approach may work. Beware I don't have how to test this patch, so you will probably have to try and tweak. -- Cheers Jorge.-
* Jorge Arellano Cid <jcid@dillo.org> [080130 14:51]:
On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote:
* Johannes Hofmann <Johannes.Hofmann@gmx.de> [080125 20:21]:
On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote:
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
Very nice! The same problem exists on DragonFly...
This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else.
What exactly is breaking? Can you provide config.log?
Here on DragonFly linking was failing with unresolved symbols, but it turned out that the problem was caused by a libiconv package that was no longer needed. The iconv stuff is now handled in libc on DragonFly...
I have attached the log. Seems like the function signature differs on OpenBSD a bit. The testcase modified as such that it includes <iconv.h> and calling iconv_open("",""); works for me when doint it manually.
I don't know what happens here...
Kind regards,
Does it fail with current CVS?
I just tried the recent cvs it is still failing... -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
Hi, On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
All,
I am very glad to see that dillo-fltk has now gained some momentum.
We too! ;)
While looking at it on FreeBSD (6.2) I came across some minor problems, patches for which are attached:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
OK with the idea but the patch "as is" breaks it for Linux. Please send a new one.
2) src-colors.h.diff
I needed to include <stdint.h> or <inttypes.h> in order to have int32_t properly defined. I decided to wrap this include in a hopefully portable and correct way by instrumenting config.h.
Committed.
3) src-dns.c.diff
On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard.
Committed, with Johannes' suggestion.
Otherwise dillo-fltk looks really promising -- keep up the good work!
I'd like to know in what sense it looks "promising" to you. -- Cheers Jorge.-
* Jorge Arellano Cid (jcid@dillo.org):
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
1) detect_libiconv.diff
src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am.
OK with the idea but the patch "as is" breaks it for Linux. Please send a new one.
Sorry, I had hoped that the autotools could deal with this somehow and since I only use FreeBSD I could only get to the "works for me" state. What does break on Linux? The intent is to check for libiconv.h in the default include path and for iconv_open in libiconv, assuming that libiconv can be located without adding -L/path/to/libiconv to LDFLAGS explicitly.
* Thomas-Martin Seck (tmseck-lists@netcologne.de):
Sorry, I had hoped that the autotools could deal with this somehow and since I only use FreeBSD I could only get to the "works for me" state. What does break on Linux? The intent is to check for libiconv.h in the default include path and for iconv_open in libiconv, assuming that libiconv can be located without adding -L/path/to/libiconv to LDFLAGS explicitly.
OK, I learned that glibc(?) nowadays includes iconv functionality. I updated the patch so that it checks for iconv_open in libc first and, failing this, in libiconv next. It still works on FreeBSD 6.2, could you please test whether this is the correct approach for Linux et al?
On Sat, Jan 19, 2008 at 05:23:50PM +0100, Thomas-Martin Seck wrote:
* Thomas-Martin Seck (tmseck-lists@netcologne.de):
Sorry, I had hoped that the autotools could deal with this somehow and since I only use FreeBSD I could only get to the "works for me" state. What does break on Linux? The intent is to check for libiconv.h in the default include path and for iconv_open in libiconv, assuming that libiconv can be located without adding -L/path/to/libiconv to LDFLAGS explicitly.
OK, I learned that glibc(?) nowadays includes iconv functionality. I updated the patch so that it checks for iconv_open in libc first and, failing this, in libiconv next. It still works on FreeBSD 6.2, could you please test whether this is the correct approach for Linux et al?
It works here, committed! Comments welcome. -- Cheers Jorge.-
* Jorge Arellano Cid (jcid@dillo.org):
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
I'd like to know in what sense it looks "promising" to you.
It can deal with UTF8 now :) But wait, I just noticed that the window title is not decoded correctly if it contains special characters, cf <http://www.heise.de/newsticker/meldung/101768> (notice the "?" in "B?rse"). No seriously, I like to have a fast, graphical, no-frills browser that allows me to read "non-active" UTF8 content since more and more content generation systems use it instead of plain ISO8859-1. What I like to see is frames support and CSS and if this is in the works I will happily waiting for it to mature -- and I am sure it will, now that a small but determined community seems to be (re-)forming. What I do not really crave for is scripting or support for active content like Flash or Jave; if all else fails, I can use Opera or FF for "demanding" sites. Unfortunately, I cannot help much with developing the core browser but offer to maintain the FreeBSD "port" of dillo2 once you consider to release it and try help with FreeBSD specific build or packaging issues. Well, as long as it does not break things for others, of course :)
On Tue, Jan 15, 2008 at 12:34:12AM +0100, Thomas-Martin Seck wrote:
* Jorge Arellano Cid (jcid@dillo.org):
On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote:
I'd like to know in what sense it looks "promising" to you.
It can deal with UTF8 now :) But wait, I just noticed that the window title is not decoded correctly if it contains special characters, cf <http://www.heise.de/newsticker/meldung/101768> (notice the "?" in "B?rse").
This is a known problem that only happens with window managers that use the WM_ICON_NAME instead of the _NET_WM_ICON_NAME property. I think this is a fltk bug (try the editor from the fltk/test directory and "save as" with a filename that contains special chars). I had sent a mail to the fltk list, but there seemed to be no consensus about my proposed fix. Johannes
No seriously, I like to have a fast, graphical, no-frills browser that allows me to read "non-active" UTF8 content since more and more content generation systems use it instead of plain ISO8859-1. What I like to see is frames support and CSS and if this is in the works I will happily waiting for it to mature -- and I am sure it will, now that a small but determined community seems to be (re-)forming.
What I do not really crave for is scripting or support for active content like Flash or Jave; if all else fails, I can use Opera or FF for "demanding" sites.
Unfortunately, I cannot help much with developing the core browser but offer to maintain the FreeBSD "port" of dillo2 once you consider to release it and try help with FreeBSD specific build or packaging issues. Well, as long as it does not break things for others, of course :)
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
participants (4)
-
Christian.Kellermann＠nefkom.net -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
tmseck-lists＠netcologne.de