AUR (en) - mingw-w64-win-iconv

Git Clone URL:	https://aur.archlinux.org/mingw-w64-win-iconv.git (read-only, click to copy)
Package Base:	mingw-w64-win-iconv
Description:	Iconv implementation using Win32 API (mingw-w64)
Upstream URL:	http://code.google.com/p/win-iconv
Keywords:	mingw mingw-w64
Licenses:	Public Domain
Conflicts:	mingw-w64-libiconv
Provides:	mingw-w64-libiconv
Submitter:	brcha
Maintainer:	None
Last Packager:	Schala
Votes:	4
Popularity:	0.000000
First Submitted:	2013-04-17 12:34 (UTC)
Last Updated:	2016-02-13 08:30 (UTC)

Latest Comments

xantares commented on 2013-11-21 09:49 (UTC)

Hello, I proposed the compromise of renaming the dll as some packages needed win-iconv, and if you were to install qt, the libiconv dll was removed and packages built against libiconv failed to execute. Now that packages dropped win-iconv, it is useless. If you want to use win-iconv you have to be aware that you have to rebuild all your packages using iconv features, or install win-iconv before building all your toolchain. xan.

Schala commented on 2013-11-20 05:09 (UTC)

I tried convincing xantares that, but I guess I did it out of fear he'd petition to orphan this.

ant32 commented on 2013-11-20 00:38 (UTC)

I am kind of pro the idea to symlink libiconv-2.dll since for me when I test my Qt programs I need a dll with that name. To test a symlink suffices. What I do is create 2 wine prefixes one for i686 and one with x86_64 with /usr/{i686,x86_64}-w64-mingw32/{bin,lib} set in PATH. My Qt programs run fine once I have it symlinked. skudo will upload qt4 soon with the dependency changed to libiconv after which I personally will stop using win-iconv. But if iconv.dll and libiconv-2.dll are not compatible I'd say don't give users a false impression. Would this prove if it was binary compatible http://www.dependencywalker.com/ ?

Schala commented on 2013-11-20 00:23 (UTC)

I am wary of this also, but I simply made a duplicate .dll with that name to appease these guys.

rubenvb commented on 2013-11-19 13:40 (UTC)

Why is the DLL being renamed at all? If you build/install this with default naming, then link to it from somewhere else, everything works, right? You shouldn't purposely introduce different libiconv-2.dll into the wild IMHO. This is something different, so let it keep its own name... Also, I hope you are aware of its limitations (quote from the readme): Win32 API does not support strict encoding conversion for some codepage. And MLang function drop or replace invalid bytes and does not return useful error status as iconv. This implementation cannot be used for encoding validation purpose. Anyways, I've never understood how this project compares to GNU libiconv in terms of features, compatibility, and performance. Does anyone have any references?