https://bugs.winehq.org/show_bug.cgi?id=54573
Bug ID: 54573 Summary: win64 bug: err:module:import_dll Library iconv.dll Product: Wine-staging Version: 8.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: romulasry@protonmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 74116 --> https://bugs.winehq.org/attachment.cgi?id=74116 wine pant.net logfile
When I run:
wine paint.net.5.0.2.install.anycpu.web.exe
See attached log.
https://bugs.winehq.org/show_bug.cgi?id=54573
romulasry@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://github.com/paintdot | |net/release/releases
https://bugs.winehq.org/show_bug.cgi?id=54573
romulasry@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Fedora
https://bugs.winehq.org/show_bug.cgi?id=54573
m8ram bram.pkm+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bram.pkm+wine@gmail.com
--- Comment #1 from m8ram bram.pkm+wine@gmail.com --- Created attachment 74143 --> https://bugs.winehq.org/attachment.cgi?id=74143 iconv.dll import error MTGA
I believe I encountered the same or a similar problem with Wizard's of the Coast Magic The Gathering Arena
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #2 from m8ram bram.pkm+wine@gmail.com --- I don't know if this DLL needs to exist within the `.wine` directory or on the Linux host. My Fedora has: $ rpm -ql mingw32-win-iconv-0.0.8-7.fc36.noarch|grep iconv.dll /usr/i686-w64-mingw32/sys-root/mingw/bin/iconv.dll /usr/i686-w64-mingw32/sys-root/mingw/lib/libiconv.dll.a $ rpm -ql mingw64-win-iconv-0.0.8-7.fc36.noarch|grep iconv.dll /usr/x86_64-w64-mingw32/sys-root/mingw/bin/iconv.dll /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libiconv.dll.a
There was no iconv.dll within the .wine directory.
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #3 from romulasry@protonmail.com --- 0124:err:module:import_dll Library iconv.dll (which is needed by L"Z:\usr\share\wine\mono\wine-mono-7.4.0\bin\libmono-2.0-x86_64.dll") not found
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #4 from m8ram bram.pkm+wine@gmail.com --- I tried the following without success: $ WINEDEBUG=-all,err WINEPATH=/usr/i686-w64-mingw32/sys-root/mingw/bin wine start "C:\Program Files\Wizards of the Coast\MTGA\MTGALauncher\MTGALauncher.exe" [m8ram@bmertens-tp ~]$ WINEPATH=/usr/i686-w64-mingw32/sys-root/mingw/bin wine start "C:\Program Files\Wizards of the Coast\MTGA\MTGALauncher\MTGALauncher.exe" 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.1 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 [m8ram@bmertens-tp ~]$ 0114:fixme:mscoree:parse_supported_runtime sku=L".NETFramework,Version=v4.5.2" not implemented 0114:fixme:mscoree:parse_supported_runtime sku=L".NETFramework,Version=v4.5.2" not implemented 0114:err:module:import_dll Loading library iconv.dll (which is needed by L"Z:\usr\share\wine\mono\wine-mono-7.4.0\bin\libmono-2.0-x86_64.dll") failed (error c000007b). 0114:err:mscoree:load_mono Could not load Mono into this process
I also tried adding the iconv.dll from ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip in ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip that does not help either
I checked winetricks but it does not include iconv.dll AFAICT
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #5 from m8ram bram.pkm+wine@gmail.com --- Created attachment 74236 --> https://bugs.winehq.org/attachment.cgi?id=74236 console logs i686 winepath
Running with the i686 version of iconv.dll added to WINEPATH gives the same error as without
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #6 from m8ram bram.pkm+wine@gmail.com --- Created attachment 74237 --> https://bugs.winehq.org/attachment.cgi?id=74237 console log running with x86_64 version added to winepath
Adding the 64bit version to the WINEPATH appears to resolve the iconv.dll error but fails with a stacktrace.
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #7 from romulasry@protonmail.com --- https://bugzilla.redhat.com/show_bug.cgi?id=2183853 load_mono Could not load Mono into this process
https://bugs.winehq.org/show_bug.cgi?id=54573
romulasry@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.2 |8.5
https://bugs.winehq.org/show_bug.cgi?id=54573
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com Keywords| |download
--- Comment #8 from Austin English austinenglish@gmail.com --- It looks like Fedora ships their own wine-mono package, that has some custom patches applied (including one related to iconv): https://src.fedoraproject.org/rpms/wine-mono/blob/rawhide/f/wine-mono.spec#_...
Does using the WineHQ provided mono package avoid this?
Try (in a clean WINEPREFIX):
$ wineboot $ wine uninstaller # remove wine-mono from inside wine uninstaller $ wget https://dl.winehq.org/wine/wine-mono/7.4.0/wine-mono-7.4.0-x86.msi $ wine msiexec /i wine-mono-7.4.0-x86.msi $ wine paint.net.5.0.2.install.anycpu.web.exe
See https://wiki.winehq.org/Mono for more info on mono, if needed.
https://bugs.winehq.org/show_bug.cgi?id=54573
Michael Cronenworth mike@cchtml.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@cchtml.com
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #9 from romulasry@protonmail.com --- It won't let me remove it from there. I tried dnf rm wine-mono but it would remove most wine packages and that isn't what I want. So I can't try that.
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.
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #11 from m8ram bram.pkm+wine@gmail.com --- A workaround for Fedora based on https://dl.winehq.org/wine/wine-mono/7.4.0/wine-mono-7.4.0-x86.msi: - remove the builtin wine mono: `wine uninstaller --remove '{E45D8920-A758-4088-B6C6-31DBB276992E}'` - Download and install the latest wine-mono: `wine ~/Downloads/wine-mono-7.4.0-x86.msi`
With this I was able to work around the issue on Fedora 37.
https://bugs.winehq.org/show_bug.cgi?id=54573
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@tsa.coop
--- Comment #12 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 56625 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #13 from Ken Sharp imwellcushtymelike@gmail.com --- Is this even a Wine bug?
https://bugs.winehq.org/show_bug.cgi?id=54573
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |1b6038f3-c0a3-4614-9a2a-256 | |434c26d0a@simplelogin.com
--- Comment #14 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 55693 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=54573
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Summary|win64 bug: |err:module:import_dll |err:module:import_dll |Library iconv.dll caused by |Library iconv.dll |Fedora patches Resolution|--- |NOTOURBUG
--- Comment #15 from Ken Sharp imwellcushtymelike@gmail.com --- Wine can't do much about third-party patches downstream.
https://bugs.winehq.org/show_bug.cgi?id=54573
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |madewokherd@gmail.com Resolution|NOTOURBUG |--- Status|RESOLVED |REOPENED
--- Comment #16 from Austin English austinenglish@gmail.com --- (In reply to Ken Sharp from comment #15)
Wine can't do much about third-party patches downstream.
It doesn't appear to be related to the patches:
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.
CC'ing Esme.
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #17 from Esme Povirk madewokherd@gmail.com --- I don't know how Wine's system path searching stuff works. We don't do anything special for resolving libmono's dependencies, just a LoadLibraryW: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/mscoree/metahost.c?re...
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #18 from Esme Povirk madewokherd@gmail.com --- Also if it matters: libmono is a native dll, not a Wine builtin.
https://bugs.winehq.org/show_bug.cgi?id=54573
Zephyr Lykos self@mochaa.ws changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |self@mochaa.ws
--- Comment #19 from Zephyr Lykos self@mochaa.ws --- Created attachment 77718 --> https://bugs.winehq.org/attachment.cgi?id=77718 [PATCH] mscoree: load libmono as a system library
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #20 from Zephyr Lykos self@mochaa.ws --- Comment on attachment 77718 --> https://bugs.winehq.org/attachment.cgi?id=77718 [PATCH] mscoree: load libmono as a system library
From 667abe0dd5769a6c605a20e650d3d76ad7043564 Mon Sep 17 00:00:00 2001 From: Zephyr Lykos git@mochaa.ws Date: Fri, 27 Dec 2024 13:54:46 +0800 Subject: [PATCH] mscoree: load libmono as a system library
This allows libmono to load extra libraries (notably win-iconv) from system_dllpath.
For example, Fedora's wine-mono is built against a shared win-iconv installed in system_dllpath, but wine will not search there unless it's explicitly instructed to do so since bfbccf1a038e (ntdll: Prevent loading Wine system dependencies in place of identically named application DLLs.).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54573 Signed-off-by: Zephyr Lykos git@mochaa.ws
dlls/mscoree/metahost.c | 2 +- dlls/ntdll/loader.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dlls/mscoree/metahost.c b/dlls/mscoree/metahost.c index e1dd00656e9..49850e69f91 100644 --- a/dlls/mscoree/metahost.c +++ b/dlls/mscoree/metahost.c @@ -192,7 +192,7 @@ static HRESULT load_mono(LPCWSTR mono_path)
if (!find_mono_dll(mono_path, mono_dll_path)) goto fail;
mono_handle = LoadLibraryW(mono_dll_path);
mono_handle = LoadLibraryExW(mono_dll_path, NULL, LDR_WINE_INTERNAL); if (!mono_handle) goto fail;diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c index 0c25fe14133..cf01e6bc7fe 100644 --- a/dlls/ntdll/loader.c +++ b/dlls/ntdll/loader.c @@ -3374,7 +3374,8 @@ NTSTATUS WINAPI DECLSPEC_HOTPATCH LdrLoadDll(LPCWSTR path_name, DWORD flags,
RtlEnterCriticalSection( &loader_section );
- nts = load_dll( path_name, dllname ? dllname : libname->Buffer, flags, &wm, FALSE );
nts = load_dll( path_name, dllname ? dllname : libname->Buffer, flags, &wm,
(flags & LDR_WINE_INTERNAL) );if (nts == STATUS_SUCCESS && !(wm->ldr.Flags & LDR_DONT_RESOLVE_REFS)) {
-- 2.47.1
https://bugs.winehq.org/show_bug.cgi?id=54573
Zephyr Lykos self@mochaa.ws changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #77718|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #21 from Zephyr Lykos self@mochaa.ws --- Created attachment 77720 --> https://bugs.winehq.org/attachment.cgi?id=77720 [PATCH v2] mscoree: load libmono as a system library
https://bugs.winehq.org/show_bug.cgi?id=54573
Zephyr Lykos self@mochaa.ws changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #77720|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #22 from Zephyr Lykos self@mochaa.ws --- Created attachment 77721 --> https://bugs.winehq.org/attachment.cgi?id=77721 [PATCH v3] mscoree: load libmono as a system library
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #23 from Rafał Mużyło galtgendo@o2.pl --- ...you know, I don't know if that's related, but I've stumbled upon a dotnet game (some really wacky, perhaps in-house engine) that fails to load d3dcompiler_47.dll unless I put a copy of in in the game dir...
I thought it's just something wacky the game/engine does, but perhaps it was due to inheriting this problem...
https://bugs.winehq.org/show_bug.cgi?id=54573
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #24 from Zephyr Lykos self@mochaa.ws --- (In reply to Rafał Mużyło from comment #23)
...you know, I don't know if that's related, but I've stumbled upon a dotnet game (some really wacky, perhaps in-house engine) that fails to load d3dcompiler_47.dll unless I put a copy of in in the game dir...
I thought it's just something wacky the game/engine does, but perhaps it was due to inheriting this problem...
I don't think d3dcompiler_47 should be considered as a "wine internal dll". Can you post a trace with WINEDEBUG="+module,+loaddll,+imports"?
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #25 from Rafał Mużyło galtgendo@o2.pl --- ...aw, shucks...
Sorry, user error, ignore the noise.
https://bugs.winehq.org/show_bug.cgi?id=54573
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine-staging |Wine Component|-unknown |ntdll
--- Comment #26 from Matteo Bruni matteo.mystral@gmail.com --- Zephyr Lykos opened an MR to attempt to fix this: https://gitlab.winehq.org/wine/wine/-/merge_requests/7077
https://bugs.winehq.org/show_bug.cgi?id=54573
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |mscoree
--- Comment #27 from Esme Povirk madewokherd@gmail.com --- Should be fixed in main branch of Wine Mono by: https://gitlab.winehq.org/mono/wine-mono/-/merge_requests/22
Thanks!
It'd be nice to get this fixed in Fedora without having to wait for a Wine Mono bump. I think that applying the patch to a revision of the Wine Mono rpm package should work, even if a broken Wine Mono was already used on the same system.
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #28 from Michael Cronenworth mike@cchtml.com --- (In reply to Esme Povirk from comment #27)
It'd be nice to get this fixed in Fedora without having to wait for a Wine Mono bump. I think that applying the patch to a revision of the Wine Mono rpm package should work, even if a broken Wine Mono was already used on the same system.
To be clear: Disregard the patch in comment #26 and only apply your patch to wine-mono?
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #29 from Esme Povirk madewokherd@gmail.com --- Just the patch from https://gitlab.winehq.org/mono/wine-mono/-/merge_requests/22
https://bugs.winehq.org/show_bug.cgi?id=54573
--- Comment #30 from Michael Cronenworth mike@cchtml.com --- Thanks. I'm pushing out a Fedora update now. Looks like this issue is finally fixed. :)
-
WineHQ Bugzilla