runtime: some programs broken on Wine after removing time compatibility hacks #34021
Comments
Afaict, this is fixed in upstream wine. Upgrade your wine. This is 1.14 material which means it's a long way off from release. |
Please read my detailed report above; I tested on Wine 4.15, which was released less than three days ago. Am I already out of date? :) |
Reverted the CL in question as of https://go-review.googlesource.com/c/go/+/192622; my bad for forgetting the issue link in the commit message. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I've started seeing panics like the one below when running some of my tests via
GOOS=windows go test -exec=wine
:If anyone wants to reproduce the crash, the Go package in question is https://github.com/mvdan/sh/tree/6af96bc17993a990fcd2c341c83a168a3158daa1/interp. I can provide a small reproducer if necessary, but I think the crash is pretty evident.
It looks like this was intentional as of https://go-review.googlesource.com/c/go/+/191759. The CL reads:
This gets a big +1 from me, of course :)
Unfortunately, the commit message didn't include a direct link to said patch or fixed bug. All I could find is this patch maintained as part of wine-staging: https://github.com/wine-staging/wine-staging/blob/a46b9ff3dcb51398cd6626f7090d8885844e1b5b/patches/ntdll-User_Shared_Data/0003-ntdll-Create-thread-to-update-user_shared_data-time-.patch
I can further prove this; the crash happens on vanilla Wine 4.15, but doesn't happen on Wine 4.15 staging.
So I don't think that Wine has handled this for some time, as the CL describes. At best, a patch has been available on wine-staging since 2017, but most users don't run wine-staging. I would personally prefer sticking to vanilla Wine, as it's more stable, and I've had no reason to use staging patches until now.
This is not an issue to report a regression and demand a revert; I understand the code in the runtime package was a hack, and that in the long term we're better off without it. However, I think we should be aware that this will break a non-trivial amount of users. And, even if Wine 4.16 shipped tomorrow with a stable fix, it would at least be a year or two before most Linux users are using that newer Wine version.
At a minimum, I think we should keep an issue like this one open, to quickly point confused users at a temporary workaround. I'm all ears on that front; I can run wine-staging for now, but that's not an ideal solution.
The text was updated successfully, but these errors were encountered: