newer version of mingw64-*-win-iconv ?

Jon Turney jon.turney@dronecode.org.uk
Sun Jun 2 14:56:45 GMT 2024


On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:
> On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:
>> It would be useful if someone could rebuild the two packages
>>    https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
>>    https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
>> based off the current git HEAD [1].
>> Reason: The current git HEAD is a reasonable alternative to
>> GNU libiconv; all encodings that it supports, other than EUC-JP
>> and GB18030, have reasonably good conversion tables. Wherease the
>> current Cygwin packages are based off source code from 2013
>> and have a major problem already with the ASCII encoding.
>> [1] https://github.com/win-iconv/win-iconv
> 
> Ran playground local and CI builds of these packages at v0.0.8 
> successfully:
> 
>      https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
> 
>      https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv
> 
> Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?
> 
> Could someone please do any further tweaks for this source git if 
> required, and do NMU builds and deploys of these?

I've given you NMU privileges, so now that someone can be you!


> [Are we really still building 32 bit mingw packages when we dropped 
> support of 32 bit Windows << 1%?

There's a difference between "we don't support running on 32-bit 
Windows" and "We don't support cross-compiling to 32-bit Windows".

Now, I'd like to do this in an evidence based manner e.g. if we had some 
statistics on packages that cygwin users choose to install, and hardly 
anyone was bothering with mingw 32-bit packages, then dropping them 
would be a good way of conserving our very limited maintainer resource.

But as previously observed, that depends on building something to 
collect that data, which SHTDI.

(There's also some unfinished work by Yaakov in a branch of the cygport 
repo which enhances cross-compile support, so that a single source 
package can produce mingw-cross install packages for multiple 
architectures, which would make it easier to continue to support these 
packages, and/or drop them in future, and/or add mingw arm64 
cross-packages when the toolchain for them exists...)



More information about the Cygwin-apps mailing list