> We already have libxml2 set up in Windows to link against the libiconv > that we distribute anyway for our own program, so it'd be more work for > us with no advantage.
For me again, the situation is currently the reverse, i.e. GTK+ apps no longer need the GNU iconv.dll, except those apps that use libxml2 will still need it. (And as libxml2 is one of the few Open Source libraries that has an official Windows binary distribution (good!), I don't want to start building own binaries of libxml2 just for this iconv.dll reason.) I guess a good compromise would be to build win_iconv also into a DLL with the same name and same ABI and API as the GNU libiconv iconv.dl... Then a packager can choose which iconv.dll to include. The preferred way to use win_iconv would still be to just build it statically into whichever DLL or EXE that needs it, but the DLL could also be used as a drop-in replacement for the GNU iconv.dll. --tml _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
