Re: [xml] Building libxml2 Windows binaries against win_iconv instead of GNU libiconv

[Igor Zlatkovic <igor zlatkovic com>]

Hello Tor,

As far as I am concerned, that is perfectly okay. However, before I can 
say yes or no, I must consult the mailing list, so I forward this 
message there.

See, according to what we see on the mailing list, the number of those 
who use libxml2 on Windows is quite large. Most of them use libxml2 in a 
more critical missions than I do. My XML files are all in plain 7-bit 
ASCII, using entity references whereever needed, and I control all of my 
XML. Most of the others aren't so lucky, they need to process markup of 
all sorts, very little of which they have control of. Many of them are 
likely not to have control over which codepages are installed on their 
Windows systems. Therefore I must let them have a say in this, it 
affects them much more than it affects me.

To all users:

Here we have a choice. Use GNU libiconv, or win_iconv on Windows. Using 
GNU libiconv means having a libxml2 which handles all encodings known to 
mankind at the price of depending on another library, namely libiconv. 
Using win_iconv means having a libxml2 which handles everything your 
setup otherwise handles, with the benefit of not being dependent on an 
additional library.

As Tor rightly pointed out, most Windows setups should be able to handle 
all that they need and if they don't, they are screwed anyway, so the 
win_iconv way should work out. However, in my history, I have worked for 
several large companies and I can say that their setups are far from 
optimal and there is little one can do about it, unless one is a CEO, or 
close.

I herewith leave the decision to the user base of libxml2 on Windows. If 
win_iconv it should be, I'll gladly adjust everything to make it that 
way. Say your opinions, oh you libxml2 users, show some democratic 
tendencies :)

Ciao,
Igor



On 25/01/08 15:38, Tor Lillqvist wrote:
> (Seems to take awfully long for my subscription to xml gnome org to be
> processed, so I send this to just you instead. Feel free to forward to
> the list.)
>
> I have a suggestion: I think it would be a good idea to in the future
> build the libxml2 Windows binaries against the "win_iconv"
> implementation of the iconv API instead of GNU libiconv.
>
> win_iconv is a quite small static library (just one smallish source
> file actually) that can be built directly into the libxml2 DLL. It
> uses the Win32 API to do the conversions. It removes the dependency on
> the rather large GNU libiconv iconv.dl.
>
> It is by Yukihiro Nakadaira, from
> http://yukihiro.nakadaira.googlepages.com/#win_iconv . I have a small
> repackaging that contains the single source file, a trivial iconv.h,
> and a (mingw) library at
> http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/win_iconv-tml-20071205.zip
> . (It is trivial to compile also with MSVC, just one source file with
> no dependencies.)
>
> As far as I can see, win_iconv works fine as a replacement for GNU
> libiconv. It supports only those encodings for which the code pages
> are present on the machine at run time, but I think all Windows
> machines should have all codepages that are relevant in practise
> installed by default. I build my current GLib and gettext distribution
> against win_iconv, and they seem to work fine.
>
> --tml