delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2008/02/11/14:41:07

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
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
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
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 <dave DOT korn AT PCYM>:
>>   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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019