void-linux
wine: wow64 quit working for specific programs
Is this a new report?
Yes
System Info
Void 6.14.2 x86_64 AuthenticAMD notuptodate hold rFFFFFFFFFFFFFFFFFFFF
Package(s) Affected
wine
Does a report exist for this bug with the project's home (upstream) and/or another distro?
possibly n/a
Expected behaviour
wine fose_loader.exe runs
Actual behaviour
Assertion failed in .\main.cpp (149): Launching Fallout failed (code = 00000057 (87))
Steps to reproduce
Build+install wine x86-64 (glibc) with wow64 - ./xbps-src pkg -o wow64 wine
wine fose_loader.exe
For a bit I've been going back to wine-10.1 because 10.2 was botched and they introduced bugs in 10.3. After using non-xbps-src to bisect the bug in 10.3, I uninstalled with make uninstall and xbps-remove, then re-installed the patched 10.5.
After this, fose quit working. I have tried to go back to 10.1, and to downgrade mesa which I am currently on a later version than Void. There are a few other packages (gmmlib, intel-media-driver) I have PRs for and updated but I didn't think they should be related.
Unsure what could have stopped this from working as it worked a few days ago before I touched wine again. Maybe there is some 'magic file' that I got rid of from an old version or something?
wine-32bit seems to run without issues. Installing wine from my git-bisect also has the same error though. I figured since this was working fine, it was probably a packaging thing, if not I can open a bug there.
(Also, side note, /bin/wine 'in srcpkgs/wine/files' reports wow64 as missing wine-32bit. I think this is just a incorrect warning because programs run fine.)
Hello.
Just tested fose_loader.exe on musl(which has the new experimental wow64 mode enabled by default) and it reaches the point where it complains about fallout3.exe missing, so I assume it runs as expected. Other programs I use for testing also work.
This indicates that either your install is broken, or the new wow64 mode is broken on x86 only.
If the failure comes later, I'd assume it's an upstream bug(given that it's experimental after all).
Regarding the "missing wine-32bit" message, it's printed if the 32bit binary is not found without checking if the new wow64 mode is enabled.
Well I can deal with it but that would unnecessarily complicate the template & launch script. My suggestion is to leave it as is, or at best extend the message with "ignore if you've enabled wow64".
Also, I am kinda struggling to follow your steps. Additionally, is there any particular reason why you wanna run it with the new experimental wow64 mode? Judging from the fact you mentioned wine-32bit works just fine, I'd assume you have both 64 & 32bit installed.
Don't get me wrong, it should still be working, but I am curious.
where it complains about fallout3.exe missing
I'm pretty sure this is different and expected. It does the same for me if you rename the exe or move where fose is.
Ya the 32bit msg is doesn't matter especially if it's not easy.
I've installed 64+32bit for now. Just wanted to test it (for stuff like this) because I'd love to kill multilib some day. It's just weird that it stopped working. Any idea why it would have been working fine until I uninstalled everything then did a install? I can make a bug over there, but ime they're not going to do any legwork, so I either bisect every version from 9.idk to 10 to see what happened with wow64
Any idea why it would have been working fine until I uninstalled everything then did a install?
Well one idea is that yes, truly they broke something in the new version given that it's under development.
The other idea is to doubt if you were even using the new wow64 mode before nuking everything. An interesting question is whether wine chooses the new experimental wow64 if it detects a 32bit install present. Any chance that was the case for you?
well ya obviously lol.
No, I didn't have wine-32bit installed. Would have complain every time like it did when I installed 32-bit and didn't remove to retry wow64 this time.
hm noticed updates pulled, pretty sure they were installed after the remove/reinstall of wine and glibc is part of them. found this https://bugs.winehq.org/show_bug.cgi?id=54336 so i'll see if there's any reply there
It's also time to remove the libOSMesa dependency. The current version of wine doesn't need it, and OSMesa was removed in the new mesa 25.1.0.
--- a/srcpkgs/wine/template
+++ b/srcpkgs/wine/template
@@ -56,11 +56,11 @@
v4l-utils-devel fontconfig-devel gnutls-devel dbus-devel sane-devel
libpcap-devel cups-devel ocl-icd-devel vulkan-loader-devel gst-plugins-base1-devel
SDL2-devel"
-depends="libXi libXinerama libXcomposite libXcursor libOSMesa
+depends="libXi libXinerama libXcomposite libXcursor
desktop-file-utils hicolor-icon-theme liberation-fonts-ttf
gnutls SDL2 wine-common>=${version}_${revision}"
lib32depends="libXi-32bit>=0 libXinerama-32bit>=0 libXcomposite-32bit>=0
- libXcursor-32bit>=0 libOSMesa-32bit>=0 desktop-file-utils>=0 hicolor-icon-theme>=0
+ libXcursor-32bit>=0 desktop-file-utils>=0 hicolor-icon-theme>=0
liberation-fonts-ttf>=0 gnutls-32bit>=0 SDL2-32bit>=0
wine-common>=${version}_${revision}"
replaces="libwine>=0"
It's also time to remove the libOSMesa dependency. The current version of wine doesn't need it, and OSMesa was removed in the new mesa 25.1.0.
--- a/srcpkgs/wine/template +++ b/srcpkgs/wine/template @@ -56,11 +56,11 @@ v4l-utils-devel fontconfig-devel gnutls-devel dbus-devel sane-devel libpcap-devel cups-devel ocl-icd-devel vulkan-loader-devel gst-plugins-base1-devel SDL2-devel" -depends="libXi libXinerama libXcomposite libXcursor libOSMesa +depends="libXi libXinerama libXcomposite libXcursor desktop-file-utils hicolor-icon-theme liberation-fonts-ttf gnutls SDL2 wine-common>=${version}_${revision}" lib32depends="libXi-32bit>=0 libXinerama-32bit>=0 libXcomposite-32bit>=0 - libXcursor-32bit>=0 libOSMesa-32bit>=0 desktop-file-utils>=0 hicolor-icon-theme>=0 + libXcursor-32bit>=0 desktop-file-utils>=0 hicolor-icon-theme>=0 liberation-fonts-ttf>=0 gnutls-32bit>=0 SDL2-32bit>=0 wine-common>=${version}_${revision}" replaces="libwine>=0"
Yes indeed, I recall discussing this in the past, and it's not just libOSMesa.
But trying to strip the package all at once might result in breakages, so I've been postponing it all this time =D.
so looks like it's here that breaks wow64 https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/sync.c?ref_type=heads#L209
if (attr->Length != sizeof(*attr)) return STATUS_INVALID_PARAMETER;
assume because of gcc update? dont see anything directly in void's wine that changed around the same time
i forgot to post here that it look like this started working again w/o patching.
not sure why or what could have updated. maybe it was in 10.13 but i didnt go back to try, i guess i'll close this?