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