https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #10 from Michael Cronenworth mike@cchtml.com --- (In reply to Austin English from comment #8)
It looks like Fedora ships their own wine-mono package, that has some custom patches applied (including one related to iconv):
There are three, small patches.
Patch 1 of 3: https://src.fedoraproject.org/rpms/wine-mono/blob/rawhide/f/wine-mono-7.3.0-...
Forces casting of the "inbytes" variable due to iconv header requirement / GCC enforcement.
Error: /builddir/build/BUILD/wine-mono-7.4.0/mono/mono/eglib/giconv.c: In function 'monoeg_g_iconv': /builddir/build/BUILD/wine-mono-7.4.0/mono/mono/eglib/giconv.c:203:39: error: passing argument 2 of 'iconv' from incompatible pointer type [-Werror=incompatible-pointer-types] 203 | return iconv (cd->cd, inbytes, inleftptr, outbytes, outleftptr); | ^~~~~~~ | | | gchar ** {aka char **} /usr/x86_64-w64-mingw32/sys-root/mingw/include/iconv.h:17:48: note: expected 'const char **' but argument is of type 'gchar **' {aka 'char **'}
Patch 2 of 3: https://src.fedoraproject.org/rpms/wine-mono/blob/rawhide/f/wine-mono-build-...
Sets build flag to statically compile in libgcc. This was added prior to the PE conversion project and therefore before MinGW binaries were required by wine. Could possibly be dropped now, but I don't suspect this is the problem.
(After testing: This patch is no longer required. I'll remove it in a future update.)
Patch 3 of 3: https://src.fedoraproject.org/rpms/wine-mono/blob/rawhide/f/wine-mono-crlf.p...
Removes carriage return characters (0x0d) that sneak into the "CABFILENAME" variable. Would not affect iconv.
(After testing: This patch is no longer required. I'll remove it in a future update.)
Fedora requires compiling from source and uses newer build tools than the upstream build environment. This has benefited Wine by fixing Python/GCC changes before they were known by upstream.
*** Workaround (assuming 64-bit WINEPREFIX): cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/iconv.dll ${WINEPREFIX}/drive_c/windows/system32/ cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libssp-0.dll ${WINEPREFIX}/drive_c/windows/system32/
Looks like wine-mono doesn't search in the system MinGW library path for DLLs. Does wine-mono perform its own DLL search path mechanism? I know 'wine' supports searching in the system path, which has me confused here.