https://bugs.winehq.org/show_bug.cgi?id=56441
Bug ID: 56441 Summary: Illegal Instruction Product: Wine Version: 0.9.3. Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: erisi@comcast.net Distribution: ---
Created attachment 76201 --> https://bugs.winehq.org/attachment.cgi?id=76201 Tracefile - was requested by Program Error Details popup
Trying to run a program. It does work under Windows arm64.
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #1 from E Risi erisi@comcast.net --- Running macOS Sonoma 14.4 on M3 Pro
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- ...and the rest of the console output ? some details about the failing program ?...
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #3 from E Risi erisi@comcast.net --- Here is the console:
(base) gene@Genes-MBP DSDPlus1p101 % wine DSDPlus.exe 0024:err:environ:init_peb starting L"Z:\Users\gene\Downloads\DSDPlus1p101\DSDPlus.exe" in experimental wow64 mode wine: Unhandled illegal instruction at address 004330FC (thread 0024), starting debugger... 00e4:err:environ:init_peb starting L"C:\windows\syswow64\winedbg.exe" in experimental wow64 mode 00e4:err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 00605a4d in module L"dsdplus" 00e4:fixme:thread:get_thread_times not implemented on this platform (base) gene@Genes-MBP DSDPlus1p101 %
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #4 from E Risi erisi@comcast.net --- The program (DSDPlus) decodes tones in an input audio stream (coming from a software defined receiver) into either text or an output audio stream that goes to the speakers. Since this is running on an M3 Pro MBP, 32 bit x86 to ARM64 translation is involved.
When I run DSDPlus in Windows 11 / ARM64 (under VMWARE) on the same MBP, it seems to run properly.
https://bugs.winehq.org/show_bug.cgi?id=56441
E Risi erisi@comcast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- OS|Linux |MacOS Hardware|x86-64 |aarch64
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #5 from E Risi erisi@comcast.net --- Is there a debug level flag I should set to gather more information?
https://bugs.winehq.org/show_bug.cgi?id=56441
temp82@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82@luukku.com
--- Comment #6 from temp82@luukku.com --- version field value dos not make sense.
https://bugs.winehq.org/show_bug.cgi?id=56441
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|0.9.3. |9.3
--- Comment #7 from Vijay Kamuju infyquest@gmail.com --- Please test with version 9.6 as it has more mac arm64 related fixes.
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #8 from E Risi erisi@comcast.net --- I have had mixed success building Wine on my M3 MBP but will try to build it.
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #9 from E Risi erisi@comcast.net --- I am not building wine 9.6 in cross compile mode successfully. When I install dependencies via BREW, they aren't being found (because Apple Mx computers use /opt instead of /usr)
The latest built version (wine-level) for MacOS is 9.3. The GitHub site has not been updated since February.
Are there detailed cross compile instructions for an Apple processor Mac?
Gene
https://bugs.winehq.org/show_bug.cgi?id=56441
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.dsdplus.com/dow | |nload-2/ Summary|Illegal Instruction |DSDPlus crashes Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #10 from E Risi erisi@comcast.net --- Created attachment 76334 --> https://bugs.winehq.org/attachment.cgi?id=76334 Illegal instruction in wine-level 9.6
https://bugs.winehq.org/show_bug.cgi?id=56441
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #11 from joaopa jeremielapuree@yahoo.fr --- Created attachment 76352 --> https://bugs.winehq.org/attachment.cgi?id=76352 screenshot showing everything is fine
No problem for me in linux
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #12 from E Risi erisi@comcast.net --- Are you running on an Intel architecture processor? Does that imply it could be a Rosetta 2 bug?
https://bugs.winehq.org/show_bug.cgi?id=56441
Brendan Shanks bshanks@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bshanks@codeweavers.com
--- Comment #13 from Brendan Shanks bshanks@codeweavers.com --- If the backtrace is accurate and the instruction it's trying to execute really is "fdisi8087_nop", then yes this is probably a Rosetta bug. Does the app crash just from launching, or do you need to load a file/start processing?
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #14 from E Risi erisi@comcast.net --- The app crashed just from launching
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #15 from Brendan Shanks bshanks@codeweavers.com --- Created attachment 76358 --> https://bugs.winehq.org/attachment.cgi?id=76358 Patch to ignore FNDISI
I tested this out, and it is a Rosetta bug (the undocumented FNDISI instruction is triggering an illegal instruction exception). I filed this as a bug with Apple. In the meantime, here's a simple patch to ignore the exception. With this, I was able to launch the app.
You'll need to build Wine from source, which can be tricky on Apple Silicon. You will need to install an Intel copy of Homebrew (separate from your ARM one), to get x86 versions of freetype, bison, maybe pkg-config for Wine to use. Running 'arch -x86_64 $SHELL' will start an emulated shell, then you can install Homebrew normally, it will install into /usr/local.
It's also easiest to build Wine from an emulated shell, you will need to make sure that the x86 Wine build doesn't try to use the ARM Homebrew libraries. Removing any '/opt/homebrew' directories from PATH should ensure that.
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #16 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 56594 has been marked as a duplicate of this bug. ***
--- Comment #17 from E Risi erisi@comcast.net --- When I run ./configure, is LDFLAGS supposed to be an exported environment variable or one of the options for the ./configure script?
--- Comment #18 from E Risi erisi@comcast.net --- When I run ./configure, I get
checking for ft2build.h... yes checking for -lfreetype... not found configure: error: FreeType 32-bit development files not found. Fonts will not be built. Use the --without-freetype option if you really want this.
I have freetype installed (via x86_64 brew). I tried adding "-L/usr/local/lib" (which is where they are located by x86 brew) to LDFLAGS but that didn't help.
How do I get configure to find the dylib?
Thanks!
--- Comment #19 from E Risi erisi@comcast.net --- When I run ./configure, I get
checking for ft2build.h... yes checking for -lfreetype... not found configure: error: FreeType 32-bit development files not found. Fonts will not be built. Use the --without-freetype option if you really want this.
I have freetype installed (via x86_64 brew). I tried adding "-L/usr/local/lib" (which is where they are located by x86 brew) to LDFLAGS but that didn't help.
How do I get configure to find the dylib?
Thanks!
--- Comment #20 from E Risi erisi@comcast.net --- For my build on an M3 in MacOS with arch = x86_64 in ZSH
Should I be using "-m64" in CC ? If I do, configure completes but make doesn't seem to work. If I don't include "-m64", configure complains that the 32 bit version of freetype can't be found (but the links for freetrype are where I think they are supposed to be.
Any suggestions?
https://bugs.winehq.org/show_bug.cgi?id=56441
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gcenx83@gmail.com
--- Comment #21 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #15)
Created attachment 76358 [details] Patch to ignore FNDISI
I tested this out, and it is a Rosetta bug (the undocumented FNDISI instruction is triggering an illegal instruction exception). I filed this as a bug with Apple. In the meantime, here's a simple patch to ignore the exception. With this, I was able to launch the app.
You'll need to build Wine from source, which can be tricky on Apple Silicon. You will need to install an Intel copy of Homebrew (separate from your ARM one), to get x86 versions of freetype, bison, maybe pkg-config for Wine to use. Running 'arch -x86_64 $SHELL' will start an emulated shell, then you can install Homebrew normally, it will install into /usr/local.
It's also easiest to build Wine from an emulated shell, you will need to make sure that the x86 Wine build doesn't try to use the ARM Homebrew libraries. Removing any '/opt/homebrew' directories from PATH should ensure that.
I've included this patch into the winehq-9.8 packages.
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #22 from Brendan Shanks bshanks@codeweavers.com --- This is fixed in macOS Sequoia. I am able to launch DSDPlus using upstream, unmodified Wine.
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #23 from Gcenx gcenx83@gmail.com --- (In reply to Brendan Shanks from comment #22)
This is fixed in macOS Sequoia. I am able to launch DSDPlus using upstream, unmodified Wine.
That’s nice to know, but I’ll probably still apply this hack just incase someone doesn’t upgrade for whatever reason.
https://bugs.winehq.org/show_bug.cgi?id=56441
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #24 from Fabian Maurer dark.shadow4@web.de --- So, can we close this as NOTOURBUG?
https://bugs.winehq.org/show_bug.cgi?id=56441
--- Comment #25 from Gcenx gcenx83@gmail.com --- (In reply to Fabian Maurer from comment #24)
So, can we close this as NOTOURBUG?
That sounds accurate to me as it’s a Rosetta2 bug that was resolved in macOS Sequoia
https://bugs.winehq.org/show_bug.cgi?id=56441
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED
--- Comment #26 from Fabian Maurer dark.shadow4@web.de --- Marking NOTOURBUG