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

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.

Sorry for the delay.

I think that is a quite good idea. Statically built packages won't care about iconv.dll and dynamic ones can be fed with either GNU iconv or win_iconv, whichever the user prefers.

It is also comfortable from the packaging point, for me. I have iconv as a separate package and adding a win_iconv won't hurt anyone. Users must deploy a package anyway, they would then just be able to choose one of the two. Most Windows users would not make a mistake in choosing either, because most of them only ever use the encodings which their machine supports anyway. I guess this is a good option.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]