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.-