The error is: /usr/bin/codesign -vvvv -f -s 226E4761426758C7A1A6C362845ADEB7BA71BA72 -o runtime --entitlements /Users/davidcox/Library/Caches/com.ohanaware.appWrapper/com.holymackerelsoftware.bambambilling/inherited.entitlements !AWEO {“code”:1,“message”:“Failed, options:193”,“type”:“troubleshooting/issuesCodeSigning.html”} !AWEO {“code”:1,“message”:“BamBam Billing.debug.app/Contents/Frameworks/XojoFramework.framework/Versions/A/XojoFramework (for architecture arm64): No such file or directory”,“type”:“troubleshooting/issuesCodeSigning.html”}
Not sure what the issues are with CodeSigning or why the XojoFramework (for architecture arm64) would be missing.
So I did a ‘Check’ in AppWrapper and all sections passed, but AppWrapper gave a whole list of 'Unable to read “”… ’ errors. Any clue how to get rid of these errors as the Help just says what they are, not how to fix them?
My guess is that somethings changed in 12.3 with the system function that gives me a fast directory listing, or AW is unable to actually access those files, due to some security setting somewhere.
Please try the following.
Disable the AW script in your Xojo project.
Open the AW file within App Wrapper.
Build your application within Xojo.
Drag the compiled application into the AW window.
Select “Wrap” from the “Process” menu on the toolbar within App Wrapper.
If that works, then try re-enabling the script and building again.
If that fails, then please use the “Contact Ohanaware” option on the Help menu and choose to include the log files so I can take a look at the processing log. I may need to build you special version of App Wrapper where I can also see the results of the fast directory iteration
I guess it’s good that I’ve been experimenting and think I have a much faster directory iteration engine that I own, looks like I might have to escalate it’s priority and finish it sooner than I originally planned.
Is that the only help page that doesn’t work? If none of the help works, with the existing error messages, it sounds like it’s been locked out of the file system. Not even able to access it’s own files.
It was happening for me with v4.3.2 and I was about to post when I saw that v4.4 was released. So I downloaded v4.4 in case that fixed the issue — it didn’t, so I posted.
I’ve spent the best part of the morning investigating this, I’ve come to the conclusion that Apple have changed how they report the number of architectures in a Mach-O file.
I’ve added some code to help me test this theory and what I hope will be a workaround. Imma little nervous to update to any 12.x beta on my development machine. Maybe I’ll blast my Big Sur partition and install it there.
If anyone else is experiencing this issue and an official release (from me) isn’t yet available, please feel free to try the current prerelease.
Last year I prototyped a new engine to replace BlackBird, it’s not fully fleshed out, but looks like I might have to re-prioritize it as it appears I can add another Apple API to the list of “Can’t trust while Tim Cook runs Apple”.