[Bug 59928] New: Std 32-bit build fails with "../wine/dlls/oleaut32/vartype.c:3000:1: internal compiler error"
http://bugs.winehq.org/show_bug.cgi?id=59928 Bug ID: 59928 Summary: Std 32-bit build fails with "../wine/dlls/oleaut32/vartype.c:3000:1: internal compiler error" Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@list.winehq.org Reporter: depaoli.renzo@gmail.com Distribution: --- Good afternoon. Environment: Debian 12 32-bit Test case: Bog standard 32-bit build attempt, .i.e. cd ~/Downloads/sources/wine.win32/ ../wine/configure make -j8 Make fails with: ../wine/dlls/oleaut32/vartype.c: In function 'VarR4FromUI8': ../wine/dlls/oleaut32/vartype.c:3000:1: internal compiler error: in assign_stack_local_1, at function.cc:429 3000 | } | ^ 0xb75c82d4 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0xb75c8397 __libc_start_main_impl ../csu/libc-start.c:360 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. make: *** [Makefile:155835: dlls/oleaut32/i386-windows/vartype.o] Error 1 make: *** Waiting for unfinished jobs.... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |depaoli.renzo@gmail.com Keywords| |regression Hardware|x86-64 |x86 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Keywords|regression | CC|depaoli.renzo@gmail.com | Component|build-env |-unknown --- Comment #1 from Ken Sharp <imwellcushtymelike@gmail.com> --- It literally tells you to report it to GCC. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Nikolay Sivov <bunglehead@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |REOPENED Ever confirmed|0 |1 --- Comment #2 from Nikolay Sivov <bunglehead@gmail.com> --- (In reply to Ken Sharp from comment #1)
It literally tells you to report it to GCC.
It doesn't mean we can't make it compile. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |depaoli.renzo@gmail.com Distribution|--- |Debian -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |build-env --- Comment #3 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Regression test result: 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4 is the first bad commit commit 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4 Author: Matteo Bruni <mbruni@codeweavers.com> Date: Tue May 19 23:16:40 2026 +0200 configure: Add -msse2 to default i386_EXTRACFLAGS. SSE2 has been supported by x86 CPUs since the Intel Pentium 4 (2000) and the AMD Athlon 64 (2003). configure | 40 ++++++++++++++++++++++++++++++++++++++++ configure.ac | 1 + 2 files changed, 41 insertions(+) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |508a30f0d37ac46c5489eb6b1ab | |f7a1013a21fe4 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Renzo de Paoli <depaoli.renzo@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #4 from Rafał Mużyło <galtgendo@o2.pl> --- So what's your processor and the full command line for compiling the file ? Also, while there's still a chance (if a low one) that this is a wine bug, did you read bug reporting guide for gcc and checked the info they require ? Not necessarily full preprocessed file, but your full compiler info... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 Bernhard Übelacker <bernhardu@mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org --- Comment #5 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 81299 --> http://bugs.winehq.org/attachment.cgi?id=81299 bookworm_amd64_i686-w64-mingw32-gcc_crash.txt Hello, I get a simlar crash of i686-w64-mingw32-gcc, I am not sure if the bug submitter used the same compiler. Here it happens withing a bwrap-chroot with Debian-bookworm-amd64 userland. Happens with these files: dlls/mfplat/main.c dlls/oleaut32/vartype.c Attached file contains some more details. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #6 from Rafał Mużyło <galtgendo@o2.pl> --- Works with gcc 13.3.1 with following CFLAGS: -O2 -g -pipe This is the tail from comment 5: -g -O1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-optimize-sibling-calls -fno-inline-functions So it works with stronger optimizations ? Or is it a matter of gcc version (still not explicitly stated) ? Still, looks more like a gcc bug... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #7 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Created attachment 81321 --> http://bugs.winehq.org/attachment.cgi?id=81321 Environment and Compiler Version -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #8 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Good morning. --- (In reply to Bernhard Übelacker from comment #5)
Created attachment 81299 [details] bookworm_amd64_i686-w64-mingw32-gcc_crash.txt
Hello, I get a simlar crash of i686-w64-mingw32-gcc, I am not sure if the bug submitter used the same compiler.
Here it happens withing a bwrap-chroot with Debian-bookworm-amd64 userland. Happens with these files: dlls/mfplat/main.c dlls/oleaut32/vartype.c
Attached file contains some more details.
Thanks Bernhard for checking and for the settings you tested with. My compiler version is the same as yours, the bog standard for Debian 12 32-bit. Please see attachment. (In reply to Rafał Mużyło from comment #4)
So what's your processor
Please see attachment. (In reply to Rafał Mużyło from comment #4)
The full command line for compiling the file ?
I don't understand the question. As stated, the problem occurs when following the Wine 32-bit build process as per https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#32-bit-only-build and/or https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#old-wow64-build (In reply to Rafał Mużyło from comment #4)
Also, while there's still a chance (if a low one) that this is a wine bug, did you read bug reporting guide for gcc and checked the info they require ?
I don't understand the statement. Wine 32-bit build worked fine until 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4. After the change, the compiler is apparently run with different settings. As a result, the Wine 32-build (and the established WoW64 build) no longer work- So this is a Wine regression. (In reply to Rafał Mużyło from comment #6)
Works with gcc 13.3.1 with following CFLAGS: -O2 -g -pipe
Could you please clarify 'what' works, which OS, which environment, what test case? 32-bit Debian? Wine 32-bit build process? (In reply to Rafał Mużyło from comment #6)
Or is it a matter of gcc version (still not explicitly stated) ?
As Bernhard stated he was able to reproduce the problem and kindly provided version information you asked for. I have attached my information now as well. (In reply to Rafał Mużyło from comment #6)
Still, looks more like a gcc bug...
Assuming for the moment an underlying, latent compiler bug, then it appears that the Wine 32-bit build process before 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4 took short-comings of the compiler into account and worked around them. The change made in Wine in 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4 broke it. --- All in all the bug should be very easy to recreate: Basic Debian 12 32-bit installation in a VM, and running the https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#32-bit-only-build That is all it takes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #9 from Rafał Mużyło <galtgendo@o2.pl> --- If you want to know, it's Gentoo for me, but my ebuild is somewhat customized (not the one currently in the tree), mostly due to minor patches. It's still a 64+32 mingw build, not new wow64 (or however it's referred to). That tail end of the command line are the CFLAGS being explicitly passed to the build, both for me and from comment 5. This is simply the part that differs for me when compared to command 5. For some laughs, my cpu is also Ryzen, but a few generations older.
As Bernhard stated he was able to reproduce the problem and kindly provided version information you asked for.
Actually, he didn't. I mean, if I were familiar with that distro, that could have meant something, but I'm not. We could assume he meant 'the tools as provided by a standard install of that distro's version', but that would be just an assumption. As cpuinfo for both of our cpus confirms sse2 support, this is a CFLAGS combination failure, so a compiler bug. As you might have noted, my gcc is kinda old, so I'm a bit curious when things broke, yet even if the wine devs decided to make some changes, the problem would still lie with gcc. Side note: after what I've wrote above, if - as google says - Debian 12 was actually using gcc 12 *and* this problem was actually fixed in gcc 13, I'd consider it quite hilarious. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #10 from Bernhard Übelacker <bernhardu@mailbox.org> --- (In reply to Rafał Mużyło from comment #9)
As Bernhard stated he was able to reproduce the problem and kindly provided version information you asked for.
Actually, he didn't. I mean, if I were familiar with that distro, that could have meant something, but I'm not. We could assume he meant 'the tools as provided by a standard install of that distro's version', but that would be just an assumption.
I thought I did ;-) I wrote "I get a simlar crash" but didn't put all information in the comment because it wasn't my bug and it was not yet clear if Renzo was using gcc or gcc-mingw because the callstack was a little different. And the attached file contains full command line and the version how the compiler identifies itself and the version from the package management. From that link [2] it may be possible that gcc-mingw 12.3 already fixed this issue. I wonder if this gcc-mingw bug could be the reason why no official bookworm 32-bit packages appear in the download directory [1], the last 32-bit package is wine-devel-i386_11.10~bookworm-1_i386.deb? [1] https://dl.winehq.org/wine-builds/debian/pool/main/w/wine/ [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111107#c13 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #11 from Rafał Mużyło <galtgendo@o2.pl> --- ...this is a bit of a riot... 1. gcc bug was filed by a *wine* dev against gcc 12.2 2. I'm not 100% certain, but it seems the fix went only into 13.4 3. To top it up, see bug 59951 comment 1 so.... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #12 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 81330 --> http://bugs.winehq.org/attachment.cgi?id=81330 59928-workaround.patch (In reply to Rafał Mużyło from comment #11)
...this is a bit of a riot...
1. gcc bug was filed by a *wine* dev against gcc 12.2 2. I'm not 100% certain, but it seems the fix went only into 13.4
The gcc bug seems to be about some unrelated alignment issue. Related to this bug I see only the comments 8 and 12 by Alex Henrie in the gcc bug.
3. To top it up, see bug 59951 comment 1
I interpret is as "there will be no official bookworm packages", but I am unsure how important to wine it is to be currently easily buildable at Bookworm systems.
so....
Yes, I also assume this bug should be closed as not-our-bug. As there won't be an easy update to Debian bookworm, and wine probably not likes to add a version check in configure, the attached 59928-workaround.patch may serve as minimal workaround, to be able to build with affected gcc-mingw. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #13 from Rafał Mużyło <galtgendo@o2.pl> ---
I interpret is as "there will be no official bookworm packages"
I interpret "since Debian 12 is EOL" as a *much* stronger statement... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #14 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Good afternoon. Quote Debian.org: The Debian 12 life cycle encompasses five years: the initial three years of full Debian support, until July 11th, 2026, and two years of Long Term Support (LTS), until June 30th, 2028. Statements that Debian 12 Bookwork is EOL are therefore incorrect. To be able to close the ticket it needs to be proven that these processes documented on the Wiki work: - Wine 32-bit build process https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#32-bit-only-build - Wine Old WoW build process https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#old-wow64-build - VM build process https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#virtual-machines It is proven that Debian 12 no longer works (for all of them) Is it confirmed that they do work with e.g. Debian 13? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #15 from Rosanne DiMesio <dimesio@earthlink.net> --- (In reply to Rafał Mużyło from comment #13)
I interpret is as "there will be no official bookworm packages"
I interpret "since Debian 12 is EOL" as a *much* stronger statement...
I meant the former; there will be no more bookworm packages here. I attempt to keep packaging for a distro until it goes EOL, but sometimes, as in this case, problems with old tools/libraries make that impossible. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #16 from Rosanne DiMesio <dimesio@earthlink.net> --- (In reply to Renzo de Paoli from comment #14)
Quote Debian.org: The Debian 12 life cycle encompasses five years: the initial three years of full Debian support, until July 11th, 2026, and two years of Long Term Support (LTS), until June 30th, 2028.
I was going by the information on https://wiki.debian.org/DebianReleases, which lists bookworm's End of Life date as 2026-06-10. If the EOL date is really a month later, that just means that if they had been buildable, 11.12 would have been our last packages for bookworm instead of 11.11.
Is it confirmed that they do work with e.g. Debian 13?
I can confirm that our Debian 13 packages built without any problem. Those packages are still the old WoW64, with the i386 packages built separately in a 32 bit container. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #17 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Created attachment 81355 --> http://bugs.winehq.org/attachment.cgi?id=81355 Patch that causes the issue Good afternoon. (In reply to Rosanne DiMesio from comment #16)
(In reply to Renzo de Paoli from comment #14)
Is it confirmed that they do work with e.g. Debian 13?
I can confirm that our Debian 13 packages built without any problem. Those packages are still the old WoW64, with the i386 packages built separately in a 32 bit container. Thanks Rosanne. I tried with Debian 13 and building Wine 32-bit worked.
(In reply to Bernhard Übelacker from comment #12)
Created attachment 81330 [details] 59928-workaround.patch
Thanks Bernhard, I tested the patch with Debian 12 and building Wine 32-bit worked. (In reply to Bernhard Übelacker from comment #12)
Yes, I also assume this bug should be closed as not-our-bug.
I reverse applied patch 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4. After the reversal, Wine 32-bit compiles again. I would appreciate it if you could check and see, if you can reproduce the behaviour. Thanks. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #18 from Renzo de Paoli <depaoli.renzo@gmail.com> --- Good afternoon Bernhard. (In reply to Bernhard Übelacker from comment #12)
Created attachment 81330 [details] 59928-workaround.patch
While the patch works for building Wine 32-bit on Debian 12, it fails for the WoW64 step. ../wine/configure --with-wine64=../wine.win64 The configure script terminates with ./config.status: 511: ../wine.win64/tools/makedep: Exec format error config.status: error: could not create Makefile The same is also true when reversing the patch that initially caused the issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #19 from Renzo de Paoli <depaoli.renzo@gmail.com> --- (In reply to Renzo de Paoli from comment #18)
While the patch works for building Wine 32-bit on Debian 12, it fails for the WoW64 step. ../wine/configure --with-wine64=../wine.win64
Please disregard, made a mistake during the builds. I can confirm that the Old WoW 64 build works on Debian with either - applying the 59928-workaround.patch or - reversing the 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4 patch I would appreciate it if this could also be verified/confirmed by other users. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #20 from Bernhard Übelacker <bernhardu@mailbox.org> --- (In reply to Renzo de Paoli from comment #19)
I can confirm that the Old WoW 64 build works on Debian with either - applying the 59928-workaround.patch or - reversing the 508a30f0d37ac46c5489eb6b1abf7a1013a21fe4 patch
As far as I understand, the 59928-workaround.patch affects just the two functions that cause gcc-mingw to crash during compilation. Reverting 508a30f0d3 affects the whole 32-bit build, with not emmiting sse2 instructions for all binaries. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59928 --- Comment #21 from Renzo de Paoli <depaoli.renzo@gmail.com> --- (In reply to Bernhard Übelacker from comment #20) Good morning Bernhard. There are 2 aspects here - testing to confirm the confirm the root cause, and - the patching to bug fix 1) (In reply to Bernhard Übelacker from comment #20)
As far as I understand, the 59928-workaround.patch affects just the two functions that cause gcc-mingw to crash during compilation. The regression test confirms that 508a30f0d3 is where things started to go wrong.
But there might be - other problems masked by it - knock-on effects/dependencies I tested the reverse application of 508a30f0d3 with the latest Wine 11.12 and did not see either, but it would be good to have another confirmation. 2) (In reply to Bernhard Übelacker from comment #20)
Reverting 508a30f0d3 affects the whole 32-bit build, with not emmiting sse2 instructions for all binaries. Correct, but as said, I am not proposing reverting 508a30f0d3 as a solution right now. (It is worth noting though that going by the check-in note of 508a30f0d3 it apparently isn't addressing any particular problem/bug/performance issue.)
For a bug fix, I think there is the matter of coding guidelines/standards for Wine? Is it permitted to have compiler checks and settings in source code or should those be handled by the configure script(s)? Thanks Bernhard. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla