X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org From: "Dave Korn" To: References: <002b01c86cdf$ddb20f40$2e08a8c0 AT CAM DOT ARTIMI DOT COM> <6910a60802111113w4b39c20aye683104e4dcbaf63 AT mail DOT gmail DOT com> Subject: RE: iconv vs. libiconv confusion Date: Mon, 11 Feb 2008 19:40:26 -0000 Message-ID: <002d01c86ce5$f35edc50$2e08a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6910a60802111113w4b39c20aye683104e4dcbaf63@mail.gmail.com> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 11 February 2008 19:13, Reini Urban wrote: > 2008/2/11, Dave Korn : >> Does anyone understand the difference between iconv_open and >> libiconv_open, and why the libiconv package supplies a header that >> declares only iconv_XXX and a library that defines only libiconv_XXXX? I >> find this confusing, and so does ./configure and friends. > > libiconv_xxx was used for a seperate and probably newer libiconv installed, Sorry, I can't parse that! > while iconv_xxx usually comes with glibc. 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. There are any number of fairly simple solutions to this clash, but I am hoping to get a slightly fuller understanding of the situation before I go further[*]. > Is libiconv from me? I'll have to check these mistakes then. Um, no, I don't think so; according to the package maintainers' list posted on 12/12 last year to -apps, Chuck W. maintains libiconv/libiconv2. > clisp, where iconv is coming from, never used libiconv_*, > its iconv.m4 just tests for the main iconv_open, _close functions. This has nothing to do with clisp. As far as I can see, you're completely off the hook, but thanks for helping anyway! cheers, DaveK [*] - My understanding of i18n is on about the same level as a tourist who thinks that translating == shouting louder! ;-) -- Can't think of a witty .sigline today.... -- 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/