sandreas
commented
2 years ago Ok, thanks. This is very useful feedback, since I do not own a Mac with M1. I'll try to give you more information to that as soon as possible.
Closed csandman closed 1 year ago
sandreas
commented
2 years ago Ok, thanks. This is very useful feedback, since I do not own a Mac with M1. I'll try to give you more information to that as soon as possible.
sandreas
commented
2 years ago Maybe have to do with this: https://github.com/dotnet/runtime/issues/49091 I did not find out wether or where @parkycai added a new issue... seems to be a problem with singlefile+ selfcontained publish, that there is no codesigning.
parkycai
commented
2 years ago Maybe have to do with this: dotnet/runtime#49091 I did not find out wether or where @parkycai added a new issue... seems to be a problem with singlefile+ selfcontained publish, that there is no codesigning.
if it's related to m1 codesign, try following command:
codesign --force --deep --sign - $targetExcutable
xattr -rds com.apple.quarantine $targetExcutableif it's related to m1 codesign, try following command:
Thx, maybe it is possible to integrate this into the automated build process as long as this is not fixed in dotnet.
parkycai
commented
2 years ago if it's related to m1 codesign, try following command:
Thx, maybe it is possible to integrate this into the automated build process as long as this is not fixed in dotnet.
I'm not sure whether you need to do it again when the excutable is moved to another macos device, but sign with a certificate issued by Apple would like do.
sandreas
commented
2 years ago I'm not sure whether you need to do it again when the excutable is moved to another macos device, but sign with a certificate issued by Apple would like do.
Thanks for pointing this out. I think this really might be a bug with C# on M1 / macOS. But I'll investigate this as soon as I have the time.
taxilian
commented
1 year ago I have built a debug version locally (on my mac studio) and it's working on my system -- just as a data point. I'm not sure what to try next, I guess maybe building a signed bundle? I have no idea how to do that
taxilian
commented
1 year ago interesting; so when I "publish" it to a directory I start having the same issue as with the downloaded binary
taxilian
commented
1 year ago doing a forced codesign did not help
taxilian
commented
1 year ago One possible hit: when running in debug mode I get this warning: objc[3305]: Class PlaceholderObject is implemented in both /Users/.../code/tone/tone/bin/Debug/net6.0/osx-arm64/tone (0x1031353f0) and /Users/.../code/tone/tone/bin/Debug/net6.0/osx-arm64/libSystem.Native.dylib (0x1239a0600). One of the two will be used. Which one is undefined.
sandreas
commented
1 year ago @taxilian Thank you very much for investigating, I really appreciate this effort.
Unfortunately I cannot reproduce or help with the problem, because I do not own an M1 / M2 Mac (and have no plans to order one...). Maybe this is a problem that I should report to dotnet itself, but I don't know if this is a compiler problem (roslyn), a runtime problem (dotnet-runtime) or something completely different.
If anyone has a clue what to do here or what the problem is, I would really appreciate any hints.
The next thing I would like to try is to use dotnet version 7.0.100 for compilation (along with other improvements in command line parsing) - this is something I will do anyway so maybe it is fixed then.
sandreas
commented
1 year ago @taxilian @parkycai @csandman
Release 0.1.3 is out and uses net7.0 for the build. Maybe (I don't have high hopes) this issue is fixed now. Feedback highly welcome.
taxilian
commented
1 year ago Sadly no
sandreas
commented
1 year ago @taxilian Thank you for quick feedback. I would like to ask some questions:
PublishSingleFile?publish / release mode, it does not work any more... did I get this right?If you compiled it from source as is and only publish did not work, I think that it would help you to create an issue on https://github.com/dotnet/runtime showing the exact steps that lead to the error.
Maybe some expert from Microsoft can tell what is happening or maybe also fix this problem?
I would prefer one of you (owning a M1) reporting this, because if there are questions, I cannot answer them without being the man in the middle just transferring all the information...
What do you think?
taxilian
commented
1 year ago Honestly I don't remember all the details at this point; the last time I did any real dotnet dev was well over a decade ago =] I was able to install vs on my mac and try the build but I'm not really familiar with any of the internals of this ecosystem anymore.
It did compile from source just fine and I could use it, but when I did "publish" (IIRC) the resulting binary did not work. I don't know anything about PublishSingleFile or other =]
sandreas
commented
1 year ago It did compile from source just fine and I could use it, but when I did "publish" (IIRC) the resulting binary did not work. I don't know anything about PublishSingleFile or other =]
Oh ok :-) Nevermind, thank you anyway. I'll try to build and publish a debug version of tone for m1 arch just for testing and we'll see what happens.
Unfortunately, net7.0 did not fix this problem as well as came with other problems, so this is not a real hope - I would love to have better news, but as it seems, tone is not working on M1 Macs for a while... :-/
sandreas
commented
1 year ago @csandman @taxilian
So here we go again - 0.1.4 is released with a Debug variant of tone only for M1... although I already lost hope that this will ever work, maybe someone finds the time to try it out and report back...?
A Debug variant is not really what I would like to publish but better than nothing...
garlik82
commented
1 year ago it doesn't. I get this error: zsh: bus error tone
sandreas
commented
1 year ago @garlik82 Thx... Very sad. Well, let's hope we find a way fixing this issue soon.
remmycat
commented
1 year ago I'm on an M2 Pro and also thought to give it a go and had the same crash.
Attaching the Problem Report (I executed tone --help)
I found this issue, which seems to be talking about the exact error we're getting: https://github.com/dotnet/runtime/issues/79267 which got a fix that was backported to dotnet 7.0.3 (https://github.com/dotnet/runtime/pull/80283).
But you mentioned dotnet 7 is bringing other problems with it?
The fix description says about the issue: When a user creates an app that uses both singlefile and compression and targets osx-arm64, the app cannot run.
This condition does seem to apply here - I see that The csproj has <PublishSingleFile>true</PublishSingleFile> and <EnableCompressionInSingleFile>true</EnableCompressionInSingleFile> set.
Without having a deeper understanding of this: Would it be possible to, e.g. turn off compression for Apple Silicon as a workaround, if it really is this exact problem?
Happy to test anything 🙂 If there's something better than the Problem Report I could do to help (on macOS), please let me know.
sandreas
commented
1 year ago @remmycat Wow, thank you for your effort and helpful description.
But you mentioned dotnet 7 is bringing other problems with it?
Yes, there were build errors with dotnet 7, but this has been a while, I learned a lot since then and dotnet 7 matured a bit... maybe I'll give it a spin in the next weeks.
Without having a deeper understanding of this: Would it be possible to, e.g. turn off compression for Apple Silicon as a workaround, if it really is this exact problem?
YES, absolutely. If this would fix the issue, I'd be happy to go without compression on macOS arm64 - better uncompressed than not working.
Thank you very much, I'll try to get this going in the build file for the next release.
sandreas
commented
1 year ago Here is a non-compressed build. I would really appreciate, when anyone with an arm64 mac could check if this really solves the problem.
I build it on Linux, so maybe it also has to be built on mac, but for now it is the only thing I can provide atm.
garlik82
commented
1 year ago No dice, same error :(
sandreas
commented
1 year ago @garlik82 Thank you for testing So I try to run some different builds with the "fixed" dotnet version on a mac and provide them in the next days.
remmycat
commented
1 year ago Actually this did fix it for me, I'm successfully running your provided version of tone on macOS with an M2 chip!
At first it didn't work, but I didn't get the usual crash dialog. The system logs say ASP: Security policy would not allow process, but after running codesign -s - tone as a workaround, it runs without crashing.
This seems like an unrelated issue, as the original SIGBUS is not happening anymore?
Edit, for more info:
Running codesign -vv tone on a fresh copy results in:
tone: code object is not signed at all
In architecture: arm64And macOS won't allow running unsigned binaries on M1/M2 as far as I can tell.
I'm unfortunately not aware of the process on how this should usually be signed in your situation (is this on dotnet?), but the following is definitely working for me right now and I'm successfully dumping metadata. Having a known workaround is a major step forwards I'd say :)
# ad-hoc code signature for tone
codesign -s - tone
# Remove quarantine flag for download (Also possible via UI by right-click + "open" on executable once)
# Might be unnecessary depending on download mechanism
xattr -d com.apple.quarantine tone Yet more info:
So after searching around a bit on the topic I think the codesigning should already work when publishing with dotnet on a macOS host (basically using apple's codesign tool internally, like I did manually). I see you're already doing that using the Github Actions - so maybe this is no problem at all for actual releases (or when you build on a mac instead of linux, like you said) :)
If still necessary, there also seem to be some options that may work to codesign cross-platform using unofficial tools like https://lib.rs/crates/apple-codesign (This project was just linked as a possible option somewhere, I cannot vouch for it working)
Last edit, I swear
Just now thought of checking on the past builds:
Yes, the existing builds of tone are already signed, this should not be an issue.
tone-0.1.4-osx-arm64 ⟫ codesign -vv tone
tone: valid on disk
tone: satisfies its Designated RequirementThe only issue that's left, but true for any macOS binary that is not signed (or notarized?) using an apple developer account and got downloaded using a browser (tarred or not) is the quarantine flag. but that should be no different to non-arm macs and there's extensive documentation on it.
sandreas
commented
1 year ago @remmycat
Actually this did fix it for me, I'm successfully running your provided version of tone on macOS with an M2 chip!
That's awesome.
Thank you so much for all the details (and edits 😋) and of course thank you for your sponsorship - I really really appreciate it. You did a lot for the tone users, because from now on I may be able to put a working tone version for M1 / M2 users online.
Let me explain:
The custom UNCOMPRESSED build was done on a Linux machine without codesign, while the official release action is using a (virtual) macOS machine, where codesign IS available. This means using the release action for the next versiontone should work out of the box on M1 / M2, when using UNCOMPRESSED option.
Here is what I will do for the next release:
quarantine flags (xattr -d com.apple.quarantine tone)Currently, I'm working on an OpenSource Cross Platform Audio Player (using Avalonia 11 xplat for Windows, Linux, Mac, Android, iOS, WASM) called Tone Audio Player, but I surely find the time to enhance tone a bit and publish a new release in the next weeks.
I'll try hard to solve this problem, until then I soon will publish a custom build done on a mac for you all to do more testing in this thread.
Thank you all for your patience and support!
remmycat
commented
1 year ago Sounds great! 🙂
One note in regards to quarantine: If someone uses wget to download the tar, as shown in the Readme, the file won't be quarantined in the first place and the mentioned command will fail with xattr: tone: No such xattr: com.apple.quarantine.
If someone is unsure, xattr -rd com.apple.quarantine tone should always work though, the -r for recursive will have it ignore files that don't have the quarantine attribute set. (similar to what @parkycai suggested before, but I don't think we need the -s to follow symlinks here)
sandreas
commented
1 year ago @remmycat @garlik82
So, as promised, here is the new uncompressed tone build from a macOS system... hopefully this solves the issues... I really need an M1 Mac for testing ;)
garlik82
commented
1 year ago Success :).
sandreas
commented
1 year ago Success :).
Awesome, thanks for the feedback and thanks again @remmycat for providing a huge contribution for solving this issue!
taxilian
commented
1 year ago it pops up the standard "we couldn't check this for malware" thing but you can get around that the usual way. it'd be cool if you could find a way to have it be notarized, but I'm not going to cast any stones if you don't want to deal with that hassle =]
Awesome
sandreas
commented
1 year ago Did a release 0.1.5 only for this - I hope it is now fixed (the release action may still not work, so I'm glad getting feedback)
garlik82
commented
1 year ago Did a release
0.1.5only for this - I hope it is now fixed (the release action may still not work, so I'm glad getting feedback)
it's working. Anytime you need something tested on apple silicon just @ me. thanks for you work.
remmycat
commented
1 year ago Yes, all fixed in 0.1.5! 🎉
Hey! this projects seems like it could definitely be useful but I wanted to let you know that it's not running on my m1 Mac. I installed following the instructions in the readme, and when I try to run
tone --helpI get this:There is also a full error log from the OS, which I'm not sure will be any help, but I figure I might as well add that too: