Seems wine was built with the new WoW64 mode, so we either have to a) use WINEARCH=wow64 by default, may break things b) ./configure --disable-wow64, keep the old behavior Reproducible: Always Steps to Reproduce: 1. `dnf install wine-core.x86_64 wine-core.i686` 2. `wineboot` 3. `wine32 cmd` (optionally export WINEDEBUG=+all) Actual Results: wine: failed to load /usr/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:environ:run_wineboot failed to start wineboot 1 wine: could not load kernel32.dll, status c0000135 Expected Results: same behavior as `wine64 cmd`.
this change was introduced in 10.2, see wine changelog.
found a workaround without major refactoring: 1. make loader aware of lib64 & lib differences (patch dlls/ntdll/unix/loader.c or symlink /usr/lib/wine/i386-* to /usr/lib64/wine/) 2. make WINEARCH=wow64 the default mode for wine64, WINEARCH=win32 the default mode for wine32 3. default to wine64
Fedora mingw-w64-gcc 15.0.1 has bugs that will crash wine with the generated PEs. You can observe this by building wine 10.0rc4 with `fedpkg --release f42 mockbuild` and `fedpkg --release rawhide mockbuild`. I'm still not sure what caused this.
Do you happen to know what all needs to be rolled by for wine to work? I tried rolling back the wine packages to a version I'm pretty sure worked before and I was still having the problem. I'm not sure if there is saved confuguration somewhere or if there are other packages I need to rollback in addition to wine stuff.
I have reverted wine, wine-dxvk and wine-mono packages to well before the problems and removed the .wine directory before tests and wine still seems to be trying to use wow64. There appears to be some state somewhere that needs to be removed or there is some other dependent package set that also needs to be rolled back. I'm not seeing any obvious ones to try. Any ideas here? The final error I get is: wine: failed to load L"\\??\\C:\\windows\\syswow64\\ntdll.dll" error c0000135
This is still broken in wine-10.4-1.fc43.x86_64.
This also affects Fedora 42 beta. Wine 10.4-1 is (still?) broken for me and cannot run any 32-bit programs. This is the version that is currently in Fedora 42 beta, so I think it's very important this gets fixed before the release. Running wineboot and then wine (or wine64) for 64-bit programs works fine. wine (or wine64 or wine32) for 32-bit programs does not work at all. $ wine ./bin/test.exe wine: failed to load L"\\??\\C:\\windows\\syswow64\\ntdll.dll" error c0000135 Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: $ wine32 ./bin/test.exe wine: failed to load /usr/lib/wine/i386-windows/ntdll.dll error 4000000e wine: could not load kernel32.dll, status c0000135 $ env WINEARCH=win32 wine ./bin/test.exe wine: WINEARCH is set to 'win32' but this is not supported in wow64 mode. $ env WINEARCH=win32 wine32 ./bin/test.exe wine: WINEARCH set to win32 but '/home/user/.wine' is a 64-bit installation. As a workaround `env WINEPREFIX=$HOME/.wine32 WINEARCH=win32 wine32 ./bin/test.exe` does work, but this requires a separate 32-bit and 64-bit wine prefixes, which the WOW64 mode which is now enabled by default is supposed to avoid.
Thanks for posting the work around. I wasn't able to figure out what I had to roll back in addition to wine to get things working. This will at least let me run something while waiting for a real fix.
Upstream packaging is placing all binaries in /opt/wine-staging/lib64/wine/. /opt/wine-staging/lib64/wine/i386-windows/ /opt/wine-staging/lib64/wine/x86_64-unix/ /opt/wine-staging/lib64/wine/x86_64-windows/ I see no option but to place symlinks for Fedora's package. /usr/lib64/wine/ i386-unix -> /usr/lib/wine/i386-unix i386-windows -> /usr/lib/wine/i386-windows x86_64-unix x86_64-windows Old prefixes will still be broken.
*** Bug 2356477 has been marked as a duplicate of this bug. ***
FEDORA-2025-8f3e54228b (wine-10.4-2.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-8f3e54228b
wine-10.4-2 seems to work normally for me. Thanks!
FEDORA-2025-8f3e54228b has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-8f3e54228b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-8f3e54228b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-0d6bddb5eb (wine-10.4-2.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2025-0d6bddb5eb
FEDORA-2025-0d6bddb5eb has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-0d6bddb5eb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-0d6bddb5eb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-8f3e54228b (wine-10.4-2.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
Fedora 42 still has 10.4-1. Does someone have to nominate 10.4-2 as a blocker or FE so that it makes it into 42 before the release?
Wine does not qualify for a blocker. You will get it as a 0-day update with the release. For now enable updates-testing to get it today.
(In reply to Michael Cronenworth from comment #18) > Wine does not qualify for a blocker. You will get it as a 0-day update with > the release. For now enable updates-testing to get it today. It wasn't found in updates-testing. Should it be in this list for f42? https://bodhi.fedoraproject.org/updates/?search=wine-10.4-2
Thanks for pointing that out. I had missed pushing an update. It will be pushed now. https://bodhi.fedoraproject.org/updates/FEDORA-2025-c2a4c8c637
FEDORA-2025-0d6bddb5eb (wine-10.4-2.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.