Message-ID: <47B10CDF.6D46108D@dessent.net>
Date: Mon, 11 Feb 2008 19:05:03 -0800
From: Brian Dessent <brian@dessent.net>
MIME-Version: 1.0
CC: cygwin@cygwin.com
Subject: Re: iconv vs. libiconv confusion
References: <002b01c86cdf$ddb20f40$2e08a8c0@CAM.ARTIMI.COM> <6910a60802111113w4b39c20aye683104e4dcbaf63@mail.gmail.com> <002d01c86ce5$f35edc50$2e08a8c0@CAM.ARTIMI.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin@cygwin.com
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Dave Korn wrote:

>   To elaborate: I'm building graphviz.  Its configure correctly spotted we
> have no iconv_xxx functions in the library, so did not define HAVE_ICONV; the
> application the supplies its own dummy stubbed-out versions of the
> iconv_open/iconv/iconv_close functions, but although those functions don't
> exist they /are/ prototyped in the header file and hence the build fails
> because the dummy versions don't have quite the same prototypes as the
> non-existing ones declared in the header file.

I ran into eactly this problem recently.  The issue is that you
accidently overwrote the libiconv header with the newlib header of the
same name (iconv.h).  You get that if you a make install (or whatever)
for newlib to get updates headers.  The newlib one doesn't work
obviously because it simply defines iconv_open.  The proper libiconv
header works correctly.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/