-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARM M1 issue Incompatible architecture: Cannot find arm64e in fat binary #136
Comments
@bezromval thanks for reporting. Yes I was expecting it. Your report "end of era ..." introduction is not so to the point and a bit negative so I removed that. I already tried to recompile the code but it does not seem to generate the ARM binary and spits errors where the code wes compiling in the previous XCode And I don't have access to any ARM machine so even if it would compile I would be unable to test this In short it may take some time before I can fix this |
------- notes for myself Main error message I get from the compiler:
Actually I'm i porting xmach/mach_types.h there. |
XCode says the file that causes the error is EMUUSBAudio_info.c I also can NOT edit this 'file'. The filename is also in italics, not clear what's going on The error says something like "in file included from /Users/wouter/Library/Developer/Xcode/DerivedData/EMUUSBAudio-fjaszixeghwepcdugnckcrbgnuhj/Build/Intermediates.noindex/EMUISBAudio.build/Debug/........ That's not where I put my source files either |
Similar error to here |
https://stackoverflow.com/questions/12132933/preprocessor-macro-for-os-x-targets gives more details but it's quite confusing |
INFOPLIST_PREPROCESS=YES is in the project settings (project.pbxproj). If I uncheck that, the error remains because cdefs.h is still imported through EMU-driver/USH.h -> IOKit/usb/StandardUSB.h -> IOKit->IOTypes.h -> IOKit/system.h -> sys/cdefs.h |
If I put #include <TargetConditionals.h> right before the #include<IOKit/usb/StandardUSB.h> then I get IOKit/usb/IOUSBLog.h file not found. Maybe this is a step in the right direction |
After just removing that import, I'm back to the TERGET_OS_OSX not defined But now through the import chain EMUUSBAudio_info.c -> mach/mach_types.h->stdint.h -> machine/types.h -> i396/types.h -> sys/cdefs.h |
Again that is NOT my file. |
This Derived Data seems wrong. https://vojtastavik.com/2018/09/02/what-is-inside-derived-data-xcode/ might help |
Is this an XCode configuration issue? |
Well that first line there is already confusing. " you install Xcode, the installer creates a /Developer/SDKs directory" I HAVE Xcode installed. But I don't have /Developer. EDIT: but XCode works fine, i now compiled the driver. That first line must be incorrect. |
The error disappears if I set in project the Apple Clang-Preprocessing / Preprocessor macros add TARGET_OS_OSX=1 EDIT: This seems indeed needed. When I remove it the build fails. But then a new error appears in EMUUSBAudioDevice.h line 249 |
If I change that line the NULL to 0 I get another error
|
https://developer.apple.com/forums/thread/72248 |
If I comment out that line, I get another error, because audioEngine.init(NULL) apparently returns boolean. I was comparing it with NULL==. After that, build succeeds! But not clear yet what that means, do we now have fat binary and how to test it |
In that building project, I now have "macOS Deployment Target" set to MacOS 10.12" and Base SDK macOS. Project format is XCode 3.2-compatible. |
I didn't understand any word you write up here, but I'm waiting here for some beta driver for M1 and would like to test it on my MacBook Air with m1 chip and I already have proper usb type c printer cable for it. Just let me know here. |
@bezromval thanks for offering help on testing. I have no ARM machine so I can not test anything. I have at this point something compiling on xcode 12.5 beta. FAIK this should support ARM compilation. But It's not clear what the compiled driver is at this point. But given that it's 458kB size, strongly suggests it's not fat but just 1 architecture. That probably is intel as I could nowhere select any ARM compilation target... The notes above are tech notes for myself, documenting what I do. I have not much time so occasionally I have a few hours. It's then essential that I can continue on, rather than redo, what I did last time. Hence all these notes. |
Yes, |
The required flags are in the project, under build settings/architecture. The Architectures are set to Standard Arcitectures (Apple Silicon, Intel) so that looks good. If I set "Build Active Architectures Only" to "Yes" it builds fine. But if I set it to No then I get another error EMUUSBAudioEngine line 47 |
Maybe the class EMUUSBAudioEngine does not implement one of the many virtual functios of the superclass? I see differences, for instance How does this work, why does it compile for debug but not for run? |
Maybe it compiles ok on intel but not on arm? If you switch the "build active architecture only' to 'yes' for debug mode, and if build by default only copmpiles the debug version? Does that imply that the superclass IOAudioEngine differs between ARM and Intel? |
Even weirder, the error ALSO shows in intel. However in spite of the error, the build succeeds there anyway. In the older compiler, there was no error at all at this place. If you look at the virtual function performFormatChange, it was always performFormatChange/4. Yet my implementation is performFormatChange/3. How can a function call with an incorrect number of args be accepted at all? The code does not say it was overriding though. What is going on here? Was the function never assumed to override/implement the virtual function? Was it never called? |
There is more detail on the error message in the issue navigator on the left. it says
|
The doc actually says "this is a new method which only exists on ARM platforms and therefore breaks binary compatibility if this is compiled on intel platforms"..... Well at least they have documented this. |
Added the missing function, only for ARM. It now compiles. |
@bezromval that input value looks nonzero to me. Is that some sort of signal? |
@bezromval Can you report the console output and post the EMUUSB messages? |
In previous Mac OSes your kext works perfect without any additional settings. |
How can I do that? |
@bezromval It's explained on the https://github.com/Wouter1/EMU-driver/blob/master/FAQ.md , "How do I make a system log of a mal-functioning driver?". |
Ok. This is when I turned on the E-mu |
When I Turned off |
Sometime its turns off sometime I get cursor frizzed,pink screen and reboot with this report after boot up CORE 0 recently retired instr at 0xfffffe002d456c0c last started kext at 2262760346: com.emu.driver.EMUUSBAudio 4.1.0 (addr 0xfffffe002c5b0000, size 49152) ** Stackshot Succeeded ** Bytes Traced 262996 (Uncompressed 671536) ** |
@bezromval thanks! It is going better than I expected. There is a connection being made with the EMU and some startup steps are taken. But either the real time stream does not work at all or there is a severe synchronization issue. Need to think about what we can do next. |
This indicates that the driver IS receiving data from the USB stream. |
@bezromval @philippgadow |
I have a friend with an M1 mac. Can ask him to connect my 0404 to hic mac. |
@oxygen311 that would be great. What I want to test is a new version of this driver. This version os on the m1 branch at https://github.com/Wouter1/EMU-driver/tree/M1 It's in the v15 directory. The installation script is NOT recognising that new file yet. Can you install the v15 driver manually in /Library/Extensions and see what it does? If it does not work, please copy the console output log for kernel and EMU to this ticket so that I might be able to see some more info. |
I not sure, that it will be able to test it that way in the near future (if it needs to copy system). So, if anyone else can do it, it'll be great too. |
@oxygen311 I see. It is safer to test it on copy to avoid any data loss. But thanks for considering anyway. |
Hi Guys, After 5 month, what is the status for ticket. Thanks! |
@svakulenko Nothing changed. Nobody was willing to help me testing and debugging the M1 version. |
Hi,
Thanks for your offer.
What might help if you can try and see whether and which error messages
are coming from the driver (see the faq/ how make system log)
However I expect that this is going to need debugging.
Debugging is possible only if I have a M1 mac and I don't expect that
happen soon.
Wouter
…------ Original Message ------
From: "Harsh Gundecha" ***@***.***>
To: "Wouter1/EMU-driver" ***@***.***>
Cc: "Wouter1" ***@***.***>; "Mention"
***@***.***>
Sent: 11/1/2021 12:53:54 PM
Subject: Re: [Wouter1/EMU-driver] ARM M1 issue Incompatible
architecture: Cannot find arm64e in fat binary (#136)
***@***.*** I'll be more than happy to help but only if we can speed things up so that it either gets working or I can return the controller before the last date or if you feel that there won't be much changes and so we are confident that we will be able to get it working given that I'll do all that I can for testing/debugging (to the extent that I don't care even if I have to reinstall macOS)
Waiting for your response.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#136 (comment)
|
Hi, I have a m1 air and e-mu 0204, if you want we can arrange a google meet session se we can debug it and make it work on m1. |
I have an M1 Max and e-mu 0202, can also contribute to testing if necessary. |
I have an m1 pro on monterery and 0202. I would be glad to contribute in testing. I've used MacBook Pro 13 2017 and your driver worked just great. I love my e-mu 0202 and would love to have a chance to start it on my new laptop. And thank you for doing it |
Be sure you're installing driver in a proper way like it described here https://motu.com/techsupport/technotes/apple-silicon-motu-audio-inst |
Do you mean you've successfully installed the driver on M1? |
@krii1988 @loveplov @bezromval @toferzim I moved away from Apple MacOS to Linux. I already had my doubts where Apple is moving, especially conserning security. Not being able to swap my drive to replacement system is a huge compromise to my security. And this showed when Apple erased my harddrive in what should have been a routine replacement of my machine's batteries. So my support for this driver is going to end here (unless I need it for some other reason at some point in the future). |
Bad mews((( I was so happy to start my old EMU card on my macbook pro 2017. Now I've upgraded to M1Pro and found it's not working anymore. It is such a pity it's not supported anymore cause it is a good sound interface. I've recorded so much great stuff on it. And most of the modern sound interfaces in this price range are so bad and unreliable. Is there anything we can do to change your mind? By the way, I've replaced my battery myself) nothing complicated at all |
Totally support the opinion up here. E-mu iis great interface even for today. It’s hard to find something with the same sound quality. |
@toferzim Yes. I attached the EMU to Ubuntu 20 and playback worked out of the box. So it might be an option to consider if you want to keep using it. Did not try recording yet though. Replacing batteries in macbook pro is not simple anymore. Everything is glued in place and you apparently need special solvents to get them out... |
Can you please describe the process of "attaching Ubuntu 20"? |
@toferzim I would first test if it works using a boot stick. I think it's explained here https://ubuntu.com/tutorials/create-a-usb-stick-on-macos#1-overview. After that you can plug in the EMU and see if you can play back and record. it's also possible to run ubuntu in a virtual box within MacOS. https://siytek.com/ubuntu-mac-virtualbox/ but I think this is technically more involved and therefore I think this has slightly less chance of working properly |
The installer report is:
The text was updated successfully, but these errors were encountered: