At 03:55 PM 11/20/02 +0100, you Andreas Fink:
I dont think so.. We ended up using it for a proprietary SMSC we connect to. Libxml's replacement functions seem only to handle character encodings needed for XML. Libiconv is also pretty std on most systems I have worked with.On Mittwoch, November 20, 2002, at 03:42 Uhr, Stipe Tolj wrote:standard libxml bails if iconv is not there. I did run into that problem on earlier MacOS X systems (10.2 and newer is ok)Oded Arbel wrote:This patch was originated from m-Wise code, so I'm not sure I'm allowed to vote on it.. but if for nothing else, at least it introduces iconv into Kannel - which I think is mighty useful. except that, all I can say is "works for me(tm)".
ok, let's interpret this as +1 :) My main concern is what the developers thing of having another hard-wired dependency to third-party software, iconv in this case.
However you can get around this by doing ./configure --without-iconv when you compile libxml. It probably has some replacement function.
Now to the stupid question. What is iconv doing at all and why do we need it?
Also if libxml has a replacement function for systems which dont have it, can we simply rely on libxml for solving it for us?
Iconv supports many charsets, so another advantage of using it is we have support for charsets that are not yet required or have not been encountered by the list yet.
I vote +1 for rolling this patch. We allready use it and it works for us, and its a real pain to keep our source base up to date when there are these differences.
Nisan
