https://bugs.winehq.org/show_bug.cgi?id=57859
Bug ID: 57859 Summary: Wine 10.2 "broken" on Ubuntu 24.04 Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: memax@gmx.fr Distribution: ---
Since I upgraded to Wine development version 10.2 using WineHQ Binary Packages on Ubuntu 24.04.2 LTS, I cannot run any application using wine or create a new prefix using wineboot.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #1 from imaxm memax@gmx.fr --- Created attachment 78077 --> https://bugs.winehq.org/attachment.cgi?id=78077 Creating a new prefix using wineboot
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #2 from imaxm memax@gmx.fr --- Created attachment 78078 --> https://bugs.winehq.org/attachment.cgi?id=78078 Running a 64bit application (already installed)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #3 from imaxm memax@gmx.fr --- Created attachment 78079 --> https://bugs.winehq.org/attachment.cgi?id=78079 Running a 32bit application (already installed)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #4 from imaxm memax@gmx.fr --- Note that I already tried to uninstall then reinstall Wine.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #5 from imaxm memax@gmx.fr --- I had to downgrade to version 10.1 to continue using Wine.
https://bugs.winehq.org/show_bug.cgi?id=57859
AndyF andreas.franz@arcor.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas.franz@arcor.de
--- Comment #6 from AndyF andreas.franz@arcor.de --- Same on Linux Mint 22.1 (based on Ubuntu 24.04).
Error thrown on "wineboot":
/opt/wine-devel/lib/wine/i386-windows/ntdll.dll error 4000000e
https://bugs.winehq.org/show_bug.cgi?id=57859
Tom Maneiro tomman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tomman@gmail.com
--- Comment #7 from Tom Maneiro tomman@gmail.com --- Can confirm the same problem here at Debian Stable (12) on amd64.
Even winecfg dies when trying to run: wine: failed to load /opt/wine-devel/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:environ:run_wineboot failed to start wineboot 1 wine: failed to load /opt/wine-devel/lib/wine/i386-windows/ntdll.dll error 4000000e wine: failed to load /opt/wine-devel/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:start:fatal_error FormatMessage failed
FWIW, that error code maps to STATUS_IMAGE_MACHINE_TYPE_MISMATCH, which means that Wine is trying to load the wrong architecture DLL for some reason. Might be related to the recent changes on WOW64 for 10.2? In any case, I'm reverting to 10.1 for now.
https://bugs.winehq.org/show_bug.cgi?id=57859
charlesthethobe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |charlesthethobe@gmail.com
--- Comment #8 from charlesthethobe@gmail.com --- Same here on Debian testing 13 (trixie)
Package: winehq-staging 10.2~trixie-1
Message on creating a new prefix: ``` $ wineboot wine: failed to open L"C:\windows\system32\wineboot.exe": c0000135 0024:err:environ:run_wineboot failed to start wineboot c0000135 wine: could not load kernel32.dll, status c0000135 ```
Message on running from the prefix of an older version: ``` $ wineboot wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:environ:run_wineboot failed to start wineboot 1 0024:fixme:winediag:loader_init wine-staging 10.2 is a testing version containing experimental patches. 0024:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:win:get_desktop_window failed to start explorer 1 wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:start:fatal_error FormatMessage failed ```
https://bugs.winehq.org/show_bug.cgi?id=57859
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
https://bugs.winehq.org/show_bug.cgi?id=57859
lyon@pvfree.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lyon@pvfree.net
--- Comment #9 from lyon@pvfree.net --- Same on Debian GNU/Linux 12 (bookworm) with wine-staging (10.2~bookworm-1):
wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:environ:run_wineboot failed to start wineboot 1 0024:fixme:winediag:loader_init wine-staging 10.2 is a testing version containing experimental patches. 0024:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:win:get_desktop_window failed to start explorer 1 wine: failed to load /opt/wine-staging/lib/wine/i386-windows/ntdll.dll error 4000000e 0024:err:start:fatal_error FormatMessage failed
https://bugs.winehq.org/show_bug.cgi?id=57859
Nathan A. Stine stinerman@proton.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stinerman@proton.me
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #10 from Tom Maneiro tomman@gmail.com --- So, to recapitulate this mess:
- ALL Debian/Ubuntu users using WineHQ upstream repos are affected by this, using ANY 10.2 release, be it -devel or -staging.
- Relevant error codes: 4000000e = STATUS_IMAGE_MACHINE_TYPE_MISMATCH c0000135 = STATUS_DLL_NOT_FOUND ...which means that the Wine loader is trying to load system DLLS from either a wrong or non-existing place.
- Cannot create new prefixes (STATUS_DLL_NOT_FOUND), cannot start anything from an already existing prefix (STATUS_IMAGE_MACHINE_TYPE_MISMATCH). Fortunately this failure mode seems harmless for existing prefixes as Wine doesn't "boot" enough to touch the Registry or any sysfile, so reverting to 10.1 is perfectly safe.
- Building 10.2 from source on the affected distros yields a perfectly functional Wine install.
- The new WOW64 dynamic mode stuff seems to require packaging changes, which were implemented for other distros served by WineHQ (for example, Arch packages are OK as per bug 57857, but downstream distro-packaged versions are broken with similar errors), so maybe said packaging changes might have been missed for the .debs? In fact, after querying Bugzilla, the ONLY reports are here (and at bug 57861, a duplicate of this one) are ALL from Debian/Ubuntu-derivative users!
Looks like those packaging rules for the .debs somehow missed the required changes for the latest WOW64 changes, which would be the very first place to look at (just wondering - I haven't packaged Wine for any distro in over a decade!)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- It looks like the same issue as bug 57857, except that this time it's the 64-bit libs that are in lib64/wine instead of lib/wine.
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine |Packaging CC| |dimesio@earthlink.net Version|10.2 |unspecified Component|-unknown |wine-packages
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #12 from Rosanne DiMesio dimesio@earthlink.net --- I did have to make packaging changes just to get the packages to build. The packages did complete without errors with the changes I made, but obviously something is still wrong.
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier.pantale@uttop.fr
--- Comment #13 from Alexandre Julliard julliard@winehq.org --- *** Bug 57868 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronaz@protonmail.com
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- *** Bug 57867 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |NM64+bugs.winehq.org@PM.me
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- *** Bug 57863 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pinkertoninrandolph@gmail.c | |om
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- *** Bug 57870 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #17 from Rosanne DiMesio dimesio@earthlink.net --- I changed the libdir to lib in the rules file and built Ubuntu 24.04 packages to test. They are on https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/xUbuntu_2.... Can someone please test them? If someone can confirm that solves the problem, I will rebuilt the other Debian/Ubuntu packages.
https://bugs.winehq.org/show_bug.cgi?id=57859
Infidelus winehq20@melsplace.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq20@melsplace.co.uk
https://bugs.winehq.org/show_bug.cgi?id=57859
Basil Dazz terry.brown@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |terry.brown@gmx.com
--- Comment #18 from Basil Dazz terry.brown@gmx.com --- (In reply to Rosanne DiMesio from comment #17)
I changed the libdir to lib in the rules file and built Ubuntu 24.04 packages to test. They are on https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/ xUbuntu_24.04/. Can someone please test them? If someone can confirm that solves the problem, I will rebuilt the other Debian/Ubuntu packages.
Built successfully and runs on Kubuntu 24.04.2, at this time using wine 10.2.
https://bugs.winehq.org/show_bug.cgi?id=57859
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |info@vlastimilburian.cz
--- Comment #19 from Zeb Figura z.figura12@gmail.com --- *** Bug 57869 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #20 from Sveinar Søpler cybermax@dexter.no --- For some odd reason, building wine myself, i can see that "wine-preloader" is not in the /bin folder as it use to, but i have 2 now. 32-bit in lib/wine/i386-unix and 64-bit in lib64/wine/x86_64-unix/ for some reason.
I might have missed some new build-method i suppose?
configure --libdir=${prefix}/lib64 --enable-win64 and 32-bit configure --libdir=${prefix}/lib --with-wine64=../build64
What changed with 10.2?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- There is now a loader (and preloader) for every platform in the corresponding -unix directory. The main loader in /usr/bin/wine is just a small wrapper that launches an appropriate platform-specific loader.
But for the loaders to be able to find each other, they need to be installed in the same libdir.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #22 from Sveinar Søpler cybermax@dexter.no --- (In reply to Alexandre Julliard from comment #21)
There is now a loader (and preloader) for every platform in the corresponding -unix directory. The main loader in /usr/bin/wine is just a small wrapper that launches an appropriate platform-specific loader.
But for the loaders to be able to find each other, they need to be installed in the same libdir.
Well.. something is awfully wrong with my buildprocess i suppose.. In the "bin" folder of my build (install), it seems most files are just symlinks to wine.. eg. regedit -> wine, wineboot -> wine and so on. Wine-10.1 and earlier these files were bash scripts and not just all symlinks to the wine binary (and no wine64 binary either).
So, i ask the same - What configure or build option should i use for this to not be all crud? Or is standard 32/64-bit builds just disabled and wow64 is the only way from 10.2+?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #23 from Alexandre Julliard julliard@winehq.org --- The symlinks replace the previous wrapper script, but the effect is the same.
There's no wine64 because the different loaders are now in the -unix directory.
There's nothing wrong with your build process, and nothing to change, except making sure that the 32- and 64-bit builds use the same libdir.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #24 from NM64+bugs.winehq.org@PM.me --- I just wanted to say that, as stated in my duplicate of this issue, this occurs even on Mint 20.x and Mint 21.x and therefore presumably *buntu 20.04 and *buntu 22.04.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #25 from Sveinar Søpler cybermax@dexter.no --- (In reply to NM64+bugs.winehq.org from comment #24)
I just wanted to say that, as stated in my duplicate of this issue, this occurs even on Mint 20.x and Mint 21.x and therefore presumably *buntu 20.04 and *buntu 22.04.
Will probably be for the whole debian family i guess..
Nevertheless, building both wine-10.2 and wine-staging-10.2 OMITTING the --libdir statement altogether seems to do the trick, and everything is in the /lib folder.
Or.. i suppose just using --libdir=${prefix}/lib for both the 32 and 64 bit compile.
Since i was not the only one missing this showstopping change, I don't feel too bad :)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #26 from Sveinar Søpler cybermax@dexter.no --- I do firmly believe that dropping "wine64" in the /bin folder will break a LOT of scripts.. winetricks +++
So, maybe add wine64 as a symlink to wine in the /bin folder just to not uppend everything, as a compatibility thing?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #27 from Alexandre Julliard julliard@winehq.org --- wine64 was already missing from new wow64 builds, so tools hopefully know how to cope with that.
https://bugs.winehq.org/show_bug.cgi?id=57859
NM64+bugs.winehq.org@PM.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|NM64+bugs.winehq.org@PM.me |
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #28 from Alexandre Julliard julliard@winehq.org --- Note that it's not just a matter of adding a symlink, the semantics are different. Until now, there were two kinds of builds:
In an "old wow64" build: wine notepad.exe -> runs 32-bit notepad wine64 notepad.exe -> runs 64-bit notepad
In a "new wow64" build: wine notepad.exe -> runs 64-bit notepad wine c:\windows\syswow64\notepad.exe -> runs 32-bit notepad wine64 doesn't exist
Starting with 10.2, all builds follow the "new wow64" scheme. This is what makes it possible to switch to new wow64 dynamically with WINEARCH=wow64. The only difference is that a pure "new wow64" build is missing the lib/wine/i386-unix directory, everything else should be identical.
Third party tools that support new wow64 mode should continue to work, they will simply see everything as new wow64.
Tools that don't support new wow64 will need to be fixed, there's no way around that.
https://bugs.winehq.org/show_bug.cgi?id=57859
stephematician@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stephematician@gmail.com
--- Comment #29 from stephematician@gmail.com --- I see this same behaviour; I also had the following issue reported while installing via `dl.winehq.org/wine-builds/ubuntu noble InRelease`:
dpkg: error processing archive /tmp/apt-dpkg-install-7weaYS/03-wine-staging-amd64_10.2~noble-2_amd64.deb (--unpack): trying to overwrite '/opt/wine-staging/bin/wine', which is also in package wine-staging-i386:i386 10.2~noble-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
https://bugs.winehq.org/show_bug.cgi?id=57859
vangli@online.no vangli@online.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vangli@online.no
--- Comment #30 from vangli@online.no vangli@online.no --- Hi
As a pure user of wine, I wonder how long time it will take to fix this? For a standard (or non-competent like me) user, this may easily been seen as a blocking bug. The core developer of wine certainly has good reasons for their decisions of the changes introduced. No complains about that.
However, such a "blocking" changes may for the standard user be extreme critical and put some uncertainty about the quality of wine, if it is not fixed very fast (a day or two). For those users of debian based system, could it be possible to release something like a "version 10.2.1.fallback" purely using version 10.1. Following normal updates, this will overwrite the failing 10.2 version following standard updates procedures, thus making wine run-able again.
This may be an idiotic proposal, but....
Bent
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #31 from vangli@online.no vangli@online.no --- Hi
See that new update was just published. Got this error:
In Norwegian: wine-devel: Depends: wine-devel-i386 (= 10.2~noble-2) men er en virtuell pakke Depends: wine-devel-amd64 (= 10.2~noble-2) men 10.2~noble-1 er installert
Translated to English: wine-devel: Depends: wine-devel-i386 (= 10.2~noble-2) but is a virtual package Depends: wine-devel-amd64 (= 10.2~noble-2) but 10.2~noble-1 is instaled
Best regards Bent
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #32 from Sveinar Søpler cybermax@dexter.no --- (In reply to vangli@online.no from comment #30)
However, such a "blocking" changes may for the standard user be extreme critical and put some uncertainty about the quality of wine, if it is not fixed very fast (a day or two). For those users of debian based system, could it be possible to release something like a "version 10.2.1.fallback" purely using version 10.1. Following normal updates, this will overwrite the failing 10.2 version following standard updates procedures, thus making wine run-able again.
This may be an idiotic proposal, but....
Bent
I do believe a 10.2-2 version is on its way that will overwrite your current 10.2 version (dont have complete list atm). This will be wine 10.2 "working", although with the limitations in place that many 3rd party tools will have some breakage (bottles, winetricks, various installers). And from what i gather from Alexandre this is intended and not a bug.
So, over the next weeks/months i suppose 3rd party maintainers must fall in line, and things get working again.
One can (mostly) always go back to previous version and put a "hold" on the version i suppose (depending on distro packagemanager). This can go bad if you do not pay a bit extra attention, so some caution is advised. I don't think there was any new library requirements with 10.2, so you should be able to just go back to 10.1 for the distro package.
https://bugs.winehq.org/show_bug.cgi?id=57859
Jason van der Waals the.jaysun99@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |the.jaysun99@gmail.com
--- Comment #33 from Jason van der Waals the.jaysun99@gmail.com --- (In reply to vangli@online.no from comment #30)
Hi
As a pure user of wine, I wonder how long time it will take to fix this? For a standard (or non-competent like me) user, this may easily been seen as a blocking bug. The core developer of wine certainly has good reasons for their decisions of the changes introduced. No complains about that.
However, such a "blocking" changes may for the standard user be extreme critical and put some uncertainty about the quality of wine, if it is not fixed very fast (a day or two). For those users of debian based system, could it be possible to release something like a "version 10.2.1.fallback" purely using version 10.1. Following normal updates, this will overwrite the failing 10.2 version following standard updates procedures, thus making wine run-able again.
This may be an idiotic proposal, but....
Bent
Hi, the packages you find here are provided by volunteers, AFAIK creating and maintaining them is not their full-time job. Many projects of this size often don't provide 1st-party, pre-built packages at all - you have build them yourself or rely exclusively on your distro's repositories.
Based on what you wrote, you should probably stick with wine-stable, as wine-devel is under active development and things are known to "break" sometimes. Last stable came out about a month ago, so most features are there. Or alternatively, use the version your distribution provides.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #34 from lyon@pvfree.net --- (In reply to stephematician from comment #29)
I see this same behaviour; I also had the following issue reported while installing via `dl.winehq.org/wine-builds/ubuntu noble InRelease`:
dpkg: error processing archive/tmp/apt-dpkg-install-7weaYS/03-wine-staging-amd64_10.2~noble-2_amd64.deb (--unpack): trying to overwrite '/opt/wine-staging/bin/wine', which is also in package wine-staging-i386:i386 10.2~noble-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
I am seeing the same conflict on Debian 12:
Preparing to unpack .../wine-staging-amd64_10.2~bookworm-2_amd64.deb ... Unpacking wine-staging-amd64 (10.2~bookworm-2) over (10.1~bookworm-1) ... dpkg: error processing archive /var/cache/apt/archives/wine-staging-amd64_10.2~bookworm-2_amd64.deb (--unpack): trying to overwrite '/opt/wine-staging/bin/wine', which is also in package wine-staging-i386:i386 10.2~bookworm-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/wine-staging-amd64_10.2~bookworm-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #35 from vangli@online.no vangli@online.no --- Related to comment 33.
Totally agreed. Removing all primary wine installation, and then follow the description on winehq, installed stable version 10.0, all works again. Also separate wine catalogs using different setups automatically was operative again.
You are all doing a superb job. No complain about that. I am grateful for what you has created, and still creates.
Bent :-)
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kieran1188@gmail.com
--- Comment #36 from Alexandre Julliard julliard@winehq.org --- *** Bug 57876 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #37 from Tom Maneiro tomman@gmail.com --- Can replicate the same conflict when building my own .DEBs with the initial 10.2 fixes on Debian Stable, and the solution seems to drop /opt/wine-$BRANCH/bin/wine from debian/wine-$BRANCH-amd64.install (since it's provided by wine-$BRANCH-i386, which is a dependency on amd64 anyway!)
Other than that, seems to be on the right path, but will check the latest updated .DEBs anyway.
FWIW: to the Debian/Ubuntu maintainer, you should add debhelper as a build-time dependnecy as without it there the .DEBs will not build under certain popular environments like pbuilder (which won't install debhelper by default, leading to early build errors - pbuilder helps with crosscompiling of the i386 bits under amd64 without polluting your system with needless 32-bit devel packages, or potentially unsolvable package conflicts).
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #38 from Tom Maneiro tomman@gmail.com --- Yep, the fix IS still needed for the upstream packages:
dpkg: error al procesar el archivo /tmp/apt-dpkg-install-5N86O8/3-wine-devel-amd64_10.2~bookworm-2_amd64.deb (--unpack): intentando sobreescribir `/opt/wine-devel/bin/wine', que está también en el paquete wine-devel-i386:i386 10.2~bookworm-2
/bin/wine WAS originally offered only by wine-$BRANCH-i386, but I'm noticing that it's an architecture-specific executable, not a script... But then, on 10.1, it's indeed i386 only (while the amd64 package provided the now-gone wine64 executable).
So... if I understand this right, the "wine" executable will always be i386/32-bit, but the magic is now done by the loaders and stuff for WOW64, right? Should it be safe to drop it then from the -amd64 package?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #39 from Alexandre Julliard julliard@winehq.org --- (In reply to Tom Maneiro from comment #38)
So... if I understand this right, the "wine" executable will always be i386/32-bit, but the magic is now done by the loaders and stuff for WOW64, right? Should it be safe to drop it then from the -amd64 package?
No, the "wine" binary should be a native binary for the host OS. Basically it should be handled exactly the same as the "wineserver" binary.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #40 from Kieran kieran1188@gmail.com --- Created attachment 78100 --> https://bugs.winehq.org/attachment.cgi?id=78100 Installation has failed - Nala Bug report
Debian Trixie
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #41 from Tom Maneiro tomman@gmail.com --- (In reply to Alexandre Julliard from comment #39)
(In reply to Tom Maneiro from comment #38)
So... if I understand this right, the "wine" executable will always be i386/32-bit, but the magic is now done by the loaders and stuff for WOW64, right? Should it be safe to drop it then from the -amd64 package?
No, the "wine" binary should be a native binary for the host OS. Basically it should be handled exactly the same as the "wineserver" binary.
Gotcha, and now that I compare package structures, /bin/wine should be moved from wine-$BRANCH-$ARCH to wine-$BRANCH, since wineserver and the other architecture-specific Linux executables live on that one too.
Gonna test this then.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #42 from Sveinar Søpler cybermax@dexter.no --- To downgrade wine-staging to previous 10.1, you can do :
sudo apt install wine-staging=10.1~jammy-1 wine-staging-amd64=10.1~jammy-1 wine-staging-dev=10.1~jammy-1 wine-staging-i386:i386=10.1~jammy-1 winehq-staging=10.1~jammy-1
This is for Ubuntu 22.04. Replace "jammy" with "noble" for 24.04... (you figure it out). Replace with wine-devel if you use that.
Then when that installs (hopefully successfully), you can do: sudo apt-mark hold wine-staging-amd64 wine-staging-dev wine-staging-i386 wine-staging winehq-staging
This will hold the packages at 10.1 until "unhold" by running: sudo apt-mark unhold wine-staging-amd64 wine-staging-dev wine-staging-i386 wine-staging winehq-staging
So, when you run sudo apt update && sudo apt upgrade, it will be listed as:
The following packages have been kept back: wine-staging wine-staging-amd64 wine-staging-dev wine-staging-i386:i386 winehq-staging
Should work the same for "debian family".
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #43 from Kieran kieran1188@gmail.com --- (In reply to Sveinar Søpler from comment #42)
To downgrade wine-staging to previous 10.1, you can do :
sudo apt install wine-staging=10.1~jammy-1 wine-staging-amd64=10.1~jammy-1 wine-staging-dev=10.1~jammy-1 wine-staging-i386:i386=10.1~jammy-1 winehq-staging=10.1~jammy-1
This is for Ubuntu 22.04. Replace "jammy" with "noble" for 24.04... (you figure it out). Replace with wine-devel if you use that.
Then when that installs (hopefully successfully), you can do: sudo apt-mark hold wine-staging-amd64 wine-staging-dev wine-staging-i386 wine-staging winehq-staging
This will hold the packages at 10.1 until "unhold" by running: sudo apt-mark unhold wine-staging-amd64 wine-staging-dev wine-staging-i386 wine-staging winehq-staging
So, when you run sudo apt update && sudo apt upgrade, it will be listed as:
The following packages have been kept back: wine-staging wine-staging-amd64 wine-staging-dev wine-staging-i386:i386 winehq-staging
Should work the same for "debian family".
Life Saver TY
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #44 from info@vlastimilburian.cz --- (In reply to Sveinar Søpler from comment #42)
To downgrade wine-staging to previous 10.1, you can do :
sudo apt install wine-staging=10.1~jammy-1 wine-staging-amd64=10.1~jammy-1 wine-staging-dev=10.1~jammy-1 wine-staging-i386:i386=10.1~jammy-1 winehq-staging=10.1~jammy-1
This is for Ubuntu 22.04. Replace "jammy" with "noble" for 24.04... (you figure it out). Replace with wine-devel if you use that.
Then when that installs (hopefully successfully), you can do: sudo apt-mark hold wine-staging-amd64 wine-staging-dev wine-staging-i386 wine-staging winehq-staging
This will hold the packages at 10.1 until "unhold" by running: sudo apt-mark unhold wine-staging-amd64 wine-staging-dev wine-staging-i386 wine-staging winehq-staging
So, when you run sudo apt update && sudo apt upgrade, it will be listed as:
The following packages have been kept back: wine-staging wine-staging-amd64 wine-staging-dev wine-staging-i386:i386 winehq-staging
Should work the same for "debian family".
Thanks, I don't downgrade packages every day, so I wanted to thank you.
Additionally, for Ubuntu Noble base, like my Mint 22 with wine-devel installed I had to adjust your command as follows, thanks again (!):
apt install wine-devel=10.1~noble-1 wine-devel-amd64=10.1~noble-1 wine-devel-dev=10.1~noble-1 wine-devel-i386:i386=10.1~noble-1 winehq-devel=10.1~noble-1
One more little thing, I had to reboot, do not know why exactly...
https://bugs.winehq.org/show_bug.cgi?id=57859
Shmerl shtetldik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik@gmail.com
--- Comment #45 from Shmerl shtetldik@gmail.com --- Trying to upgrade Wine in Debian testing and packages are currently broken:
dpkg: error processing archive /var/cache/apt/archives/wine-devel-amd64_10.2~trixie-2_amd64.deb (--unpack): trying to overwrite '/opt/wine-devel/bin/wine', which is also in package wine-devel-i386:i386 (10.2~trixie-2) dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #46 from Shmerl shtetldik@gmail.com --- Also, this is probably related:
https://bugs.winehq.org/show_bug.cgi?id=57861
https://bugs.winehq.org/show_bug.cgi?id=57859
BENDER35 grandrodri3@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grandrodri3@gmail.com
--- Comment #47 from BENDER35 grandrodri3@gmail.com --- hello.
Here I have the same problem, I have xubuntu 24.04 with the active extension (ubuntu PRO), I say this for the following reason, when updating the .wine folder I got the same ntdll.dll error when updating to 10.2, I uninstalled winehq-devel with the removal of configuration files, I reinstalled it and it gave me the same error, I deleted the .wine folder, I typed the winecfg and it gave me an error in kernel32, I uninstalled winehq-devel, installed the staging and it gave me the same error, I uninstalled the staging and installed the stable, it let me create the .wine and started the winecfg, there must be something wrong with the 32-bit dependencies that is giving the error, what has happened to me is that for a few days the livepatch shield icon did not appear (but its snap continued to work) now the icon appears perfectly.
greetings
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #48 from Rosanne DiMesio dimesio@earthlink.net --- *** Bug 57861 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine 10.2 "broken" on |WineHQ 10.2 packages broken |Ubuntu 24.04 |on Ubuntu/Debian
https://bugs.winehq.org/show_bug.cgi?id=57859
Mark mfraz74@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mfraz74@gmail.com
--- Comment #49 from Mark mfraz74@gmail.com --- Came across this yesterday after having to do a new install of Ubuntu 24.04 and thinking I'd messed up.
10.2~noble-2 is available now except that I'm now getting the error dpkg: error processing archive /tmp/apt-dpkg-install-2BfZ8I/70-wine-devel-amd64_10.2~noble-2_amd64.deb (--unpack): trying to overwrite '/opt/wine-devel/bin/wine', which is also in package wine-devel-i386:i386 10.2~noble-2
https://bugs.winehq.org/show_bug.cgi?id=57859
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #50 from Rosanne DiMesio dimesio@earthlink.net --- I have another set of wine-devel packages to test, for Debian 12 and Ubuntu 24.04.
https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/Debian_12... https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/xUbuntu_2...
Please test and confirm whether this solves the existing packaging problems without creating new ones.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #51 from Alexandre Julliard julliard@winehq.org --- *** Bug 57879 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #52 from Nathan A. Stine stinerman@proton.me --- (In reply to Rosanne DiMesio from comment #50)
I have another set of wine-devel packages to test, for Debian 12 and Ubuntu 24.04.
https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/Debian_12... https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/ xUbuntu_24.04/
Please test and confirm whether this solves the existing packaging problems without creating new ones.
Works for me, Rosanne. Running Debian Bookworm amd64.
Tested: winecfg and a 32-bit game (Civ 4). Both are working fine. No errors on the install.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #53 from Tom Maneiro tomman@gmail.com --- (In reply to Rosanne DiMesio from comment #50)
I have another set of wine-devel packages to test, for Debian 12 and Ubuntu 24.04.
https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/Debian_12... https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/ xUbuntu_24.04/
Please test and confirm whether this solves the existing packaging problems without creating new ones.
Debian 12, good to go here~!
Tested on a existing prefix, running both 32 and 64-bit executables, everything worked as it should.
Indeed the missing part was to move /bin/wine to the architecture-specific wine-$BRANCH package.
https://bugs.winehq.org/show_bug.cgi?id=57859
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |contramuffin@gmail.com
--- Comment #54 from Alexandre Julliard julliard@winehq.org --- *** Bug 57880 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #55 from Kieran kieran1188@gmail.com --- Any updates on a fix? I'm using wine repos
https://bugs.winehq.org/show_bug.cgi?id=57859
J White jwhite88@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jwhite88@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=57859
zefkerr zefkerrigan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zefkerrigan@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #56 from Kieran kieran1188@gmail.com --- Tried to update to 10.2 trixie-4 and still have the same issue
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #57 from Kieran kieran1188@gmail.com --- Created attachment 78105 --> https://bugs.winehq.org/attachment.cgi?id=78105 wine-devel_10.2~trixie-4 debug log
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #58 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Kieran from comment #56)
Tried to update to 10.2 trixie-4 and still have the same issue
Try uninstalling 10.2 trixie-1 first.
https://bugs.winehq.org/show_bug.cgi?id=57859
CWB cwbussard@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cwbussard@gmail.com
--- Comment #59 from CWB cwbussard@gmail.com --- I'm getting the same fail to upgrade as Kieran.
HOWEVER, this time sudo apt --fix-broken install is able to fix it. (It was not able to fix 10.2-trixie-2.)
https://bugs.winehq.org/show_bug.cgi?id=57859
Olivier Pantalé olivier.pantale@uttop.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|olivier.pantale@uttop.fr |
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #60 from imaxm memax@gmx.fr --- Created attachment 78106 --> https://bugs.winehq.org/attachment.cgi?id=78106 Error when upgrading wine-devel from 10.1~noble-1 to 10.2~noble-4 on Ubuntu 24.04
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #61 from Shmerl shtetldik@gmail.com --- I was able to upgrade by first removing all wine packages and then installing them again.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #62 from Kieran kieran1188@gmail.com --- (In reply to Shmerl from comment #61)
I was able to upgrade by first removing all wine packages and then installing them again.
Confirm working?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #63 from Shmerl shtetldik@gmail.com --- (In reply to Kieran from comment #62)
Confirm working?
Yes, all works fine (Debian testing, 10.2~trixie-4 packages).
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #64 from Kieran kieran1188@gmail.com --- (In reply to Shmerl from comment #63)
(In reply to Kieran from comment #62)
Confirm working?
Yes, all works fine (Debian testing, 10.2~trixie-4 packages).
TY just tried fixed and working perfectly. ty for the update
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #65 from Sveinar Søpler cybermax@dexter.no --- (In reply to Shmerl from comment #61)
I was able to upgrade by first removing all wine packages and then installing them again.
Yeah, same for Ubuntu 24.04. But seems to be working "as intended" now atleast.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #66 from Sveinar Søpler cybermax@dexter.no --- I do however see that the latest 10.2~noble-4 version still adds the following symlinks:
/usr/bin/wine64 -> /opt/wine-staging/bin/wine64 /usr/bin/wine64-preloader -> /opt/wine-staging/bin/wine64-preloader /usr/bin/wine-preloader -> /opt/wine-staging/bin/wine-preloader
Although not really breaking, it does not look as it is supposed to be there anymore...
Possibly some tweaking to the debian/wine-XX-amd64.postinst debian/wine-XX-i386.postinst
and debian/wine-XX-amd64.lintian-overrides debian/wine-XX-i386.lintian-overrides
And the debian/rules file still seem to create symlinks to wine-preloader for some reason.
Since one now have 2 "wine-preloader" binaries each in its own /opt/wine-staging/lib/wine/x86_64-unix/ /opt/wine-staging/lib/wine/i386-unix/
I suppose they are no longer used in the same way, and should not be symlinked to /usr/bin?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #67 from Shmerl shtetldik@gmail.com --- (In reply to Sveinar Søpler from comment #66)
I do however see that the latest 10.2~noble-4 version still adds the following symlinks:
/usr/bin/wine64 -> /opt/wine-staging/bin/wine64 /usr/bin/wine64-preloader -> /opt/wine-staging/bin/wine64-preloader /usr/bin/wine-preloader -> /opt/wine-staging/bin/wine-preloader
For the reference, I don't see any wine64 symlinks in Debian.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #68 from Tom Maneiro tomman@gmail.com --- (In reply to Shmerl from comment #67)
(In reply to Sveinar Søpler from comment #66)
I do however see that the latest 10.2~noble-4 version still adds the following symlinks:
/usr/bin/wine64 -> /opt/wine-staging/bin/wine64 /usr/bin/wine64-preloader -> /opt/wine-staging/bin/wine64-preloader /usr/bin/wine-preloader -> /opt/wine-staging/bin/wine-preloader
For the reference, I don't see any wine64 symlinks in Debian.
Neither I see anything like that here. The only noise I get is during the postinstall phase, where I notice references to no longer existing wine-preloader binaries:
Configurando wine-devel-i386:i386 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine-preloader (No such file or directory) Configurando wine-devel-amd64 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine64-preloader (No such file or directory) Configurando wine-devel (10.2~bookworm-4) ... Configurando winehq-devel (10.2~bookworm-4) ...
...aside of that, seems everything else finally fell into its proper place, so this 4th release should be safe for upgrading.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #69 from Shmerl shtetldik@gmail.com --- Sorry for slight off-topic, but since above is related to the whole new wow64 mode and someone might know, do I still need to set LD_LIBRARY_PATH when running non default location of wine?
I.e. before I used this kind of wrapper environment set up script (where I set wine_path as base location of the custom Wine I want to use:
if [[ "${wine_path+isset}" ]]; then export PATH=${wine_path}/bin:$PATH
if [[ -e "${wine_path}/lib/wine/x86_64-unix" ]]; then export LD_LIBRARY_PATH="${wine_path}/lib/wine/x86_64-unix:${LD_LIBRARY_PATH}" fi
if [[ -e "${wine_path}/lib/wine/i386-unix" ]]; then export LD_LIBRARY_PATH="${wine_path}/lib/wine/i386-unix:${LD_LIBRARY_PATH}" fi fi
Is this still necessary with latest wine or it finds its *.so libs correctly on its own?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #70 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Tom Maneiro from comment #68)
(In reply to Shmerl from comment #67)
(In reply to Sveinar Søpler from comment #66)
I do however see that the latest 10.2~noble-4 version still adds the following symlinks:
/usr/bin/wine64 -> /opt/wine-staging/bin/wine64 /usr/bin/wine64-preloader -> /opt/wine-staging/bin/wine64-preloader /usr/bin/wine-preloader -> /opt/wine-staging/bin/wine-preloader
For the reference, I don't see any wine64 symlinks in Debian.
Neither I see anything like that here. The only noise I get is during the postinstall phase, where I notice references to no longer existing wine-preloader binaries:
Configurando wine-devel-i386:i386 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine-preloader (No such file or directory) Configurando wine-devel-amd64 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine64-preloader (No such file or directory) Configurando wine-devel (10.2~bookworm-4) ... Configurando winehq-devel (10.2~bookworm-4) ...
...aside of that, seems everything else finally fell into its proper place, so this 4th release should be safe for upgrading.
There are still some things that need to be cleaned up, (some misplaced man pages, too) but nothing that breaks anything, so it can wait for 10.3.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #71 from Shmerl shtetldik@gmail.com --- To answer my question, I did some digging running a custom Wine without doing LD_LIBRARY_PATH. lsof confirms that correct .so's are opened and stock Wine's so aren't. So no need to do LD_LIBRARY_PATH anymore if anyone wonders.
https://bugs.winehq.org/show_bug.cgi?id=57859
stephematician@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stephematician@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #72 from Sveinar Søpler cybermax@dexter.no --- (In reply to Tom Maneiro from comment #68)
(In reply to Shmerl from comment #67)
(In reply to Sveinar Søpler from comment #66)
I do however see that the latest 10.2~noble-4 version still adds the following symlinks:
/usr/bin/wine64 -> /opt/wine-staging/bin/wine64 /usr/bin/wine64-preloader -> /opt/wine-staging/bin/wine64-preloader /usr/bin/wine-preloader -> /opt/wine-staging/bin/wine-preloader
For the reference, I don't see any wine64 symlinks in Debian.
Neither I see anything like that here. The only noise I get is during the postinstall phase, where I notice references to no longer existing wine-preloader binaries:
Configurando wine-devel-i386:i386 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine-preloader (No such file or directory) Configurando wine-devel-amd64 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine64-preloader (No such file or directory) Configurando wine-devel (10.2~bookworm-4) ... Configurando winehq-devel (10.2~bookworm-4) ...
...aside of that, seems everything else finally fell into its proper place, so this 4th release should be safe for upgrading.
That "noise" is the .deb packages trying to symlink non-existing binaries afaik.
Have you done a "sudo updatedb & locate wine64" and check that you dont have those symlinks in /usr/bin, /bin or /sbin or whatever system folder Debian puts stuff in?
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #73 from Tom Maneiro tomman@gmail.com --- (In reply to Sveinar Søpler from comment #72)
(In reply to Tom Maneiro from comment #68)
(In reply to Shmerl from comment #67)
(In reply to Sveinar Søpler from comment #66)
I do however see that the latest 10.2~noble-4 version still adds the following symlinks:
/usr/bin/wine64 -> /opt/wine-staging/bin/wine64 /usr/bin/wine64-preloader -> /opt/wine-staging/bin/wine64-preloader /usr/bin/wine-preloader -> /opt/wine-staging/bin/wine-preloader
For the reference, I don't see any wine64 symlinks in Debian.
Neither I see anything like that here. The only noise I get is during the postinstall phase, where I notice references to no longer existing wine-preloader binaries:
Configurando wine-devel-i386:i386 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine-preloader (No such file or directory) Configurando wine-devel-amd64 (10.2~bookworm-4) ... /opt/wine-devel/bin/wine64-preloader (No such file or directory) Configurando wine-devel (10.2~bookworm-4) ... Configurando winehq-devel (10.2~bookworm-4) ...
...aside of that, seems everything else finally fell into its proper place, so this 4th release should be safe for upgrading.
That "noise" is the .deb packages trying to symlink non-existing binaries afaik.
Have you done a "sudo updatedb & locate wine64" and check that you dont have those symlinks in /usr/bin, /bin or /sbin or whatever system folder Debian puts stuff in?
Indeed, such a check tells me that both "wine64/wine64-preloader" symlinks exist at /usr/bin/, and furthermore a query via dpkg -S confirms they both were put there by... winehq-devel. Same deal with wine-preloader (which no longer lives at /opt/wine-devel/bin), and whose /usr/bin/ symlink is also put there by winehq-devel.
So add that to the cleanup tasks for the packaging files then.
https://bugs.winehq.org/show_bug.cgi?id=57859
aaronaz@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|aaronaz@protonmail.com |
https://bugs.winehq.org/show_bug.cgi?id=57859
bkanuka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bkanuka@gmail.com
--- Comment #74 from bkanuka@gmail.com --- FWIW I was experiencing this yesterday, but now no problems installing/upgrading to 10.2 (wine-devel). And I'm using the offical repos, not the testing ones in this thread.
Personally, I would say this is confirmed fixed.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #75 from CWB cwbussard@gmail.com --- (In reply to Alexandre Julliard from comment #28)
Starting with 10.2, all builds follow the "new wow64" scheme. This is what makes it possible to switch to new wow64 dynamically with WINEARCH=wow64.
A bit off topic, but I'd like some clarification on this.
Am I understanding correctly that `WINEARCH=wow64 wine somewin32.exe` will use the new wow64 mode, while anything else will use the old one? Does it matter how the prefix was initially created? (Does it work in an existing win64 prefix? Does it work in an existing win32 prefix? Is there such a thing as a wow64 prefix?)
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #76 from Shmerl shtetldik@gmail.com --- (In reply to CWB from comment #75)
Am I understanding correctly that `WINEARCH=wow64 wine somewin32.exe` will use the new wow64 mode, while anything else will use the old one? Does it matter how the prefix was initially created? (Does it work in an existing win64 prefix? Does it work in an existing win32 prefix? Is there such a thing as a wow64 prefix?)
Not sure if there is a flavor of wow64 prefix, but to your other question - yes, from my testing if you run a 32-bit program in a 64-bit prefix that was created in the past (or now), it will use 32-bit libraries proper using the old style wow64, but if you set WINEARCH=wow64, it will use 64-bit libraries in that special thunking mode (new style of wow64).
I.e. basically you can now do both with forcing the new mode with a variable. I don't use 32-bit prefixes anymore since there is really no point in them so can't say what will happen there, but wow64 is irrelevant for them anyway.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #77 from Alexandre Julliard julliard@winehq.org --- There's no special wow64 prefix, old and new wow64 mode use the exact same 64-bit prefixes.
You can't use a 32-bit prefix in new wow64 mode, since it needs 64-bit dlls.
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #78 from BENDER35 grandrodri3@gmail.com --- Hi guys
I opened a virtual machine that I had with Ubuntu Budgie and it turns out that I had 10.2 Devel installed (it's not staging) and when I updated it it didn't work, I'm posting it because I got a curious error when applying the apt-get upgrade, I'm posting the log below:
002c:err:module:import_dll Loading library advapi32.dll (which is needed by L"C:\windows\system32\wineboot.exe") failed (error c000012f). 002c:err:module:import_dll Loading library ucrtbase.dll (which is needed by L"C:\windows\system32\wineboot.exe") failed (error c000012f). 002c:err:module:import_dll Loading library ucrtbase.dll (which is needed by L"C:\windows\system32\ws2_32.dll") failed (error c000012f). 002c:err:module:import_dll Library ws2_32.dll (which is needed by L"C:\windows\system32\wineboot.exe") not found 002c:err:module:loader_init Importing dlls for L"C:\windows\system32\wineboot.exe" failed, status c0000135 wine: could not load kernel32.dll, status c000012f
and below is part of the output that apt-get upgrade gives me:
... Configuring wine-devel-amd64 (10.2~jammy-4) ... /opt/wine-devel/bin/wine64-preloader (No such file or directory)
------------------ ....................... Configuring wine-devel-i386:i386 (10.2~jammy-4) ... /opt/wine-devel/bin/wine-preloader (No such file or directory)
Greetings
https://bugs.winehq.org/show_bug.cgi?id=57859
--- Comment #79 from Shmerl shtetldik@gmail.com --- (In reply to BENDER35 from comment #78)
Hi guys
I opened a virtual machine that I had with Ubuntu Budgie and it turns out that I had 10.2 Devel installed (it's not staging) and when I updated it it didn't work, I'm posting it because I got a curious error when applying the apt-get upgrade, I'm posting the log below:
Try removing all wine packages, do apt update and install again.
https://bugs.winehq.org/show_bug.cgi?id=57859
charlesthethobe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|charlesthethobe@gmail.com |
-
WineHQ Bugzilla