-
Notifications
You must be signed in to change notification settings - Fork 38
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
Revert AudioUnit/AudioToolbox linking change but put AudioUnit first #49
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this builds for iOS and macOS, this is fine with me. It's unclear to me how order would change the linking error @clangdo mentioned in their ci. I could see how order would matter for headers in bindgen but this seems to be after the bindgen phase.
Would you be up to adding #38 to part of this PR? I can follow up otherwise.
Wow you folks are really quick with these things, are you sure this won't backfire on people who just want the |
There's a reason this is a draft PR. :) I was going to re-test everything first but had trouble connecting XCode to my iPhone the other night. FYI @simlay the reason for the swap was linked in the issue, this link https://forum.juce.com/t/plug-in-built-with-xcode-11-fails-to-load-on-yosemite-10-10/35912/44 I stumbled across. I figured swapping the order can't hurt? At the same time, we can leave this all alone, if it's not broken don't fix it. Anyway I now see the edit in the linked issue, so it did work at some point. @simlay if you have time feel free to push ahead with adding the cross-compilation tests. I can help with some testing in general. I only have a small amount of time on weekends to give this any attention. |
I was also consdering linking AudioUnit and AudioToolbox for the AudioUnit feature flag (not just reverting the change) if it was necessary after a round of testing. But I was able to build for macOS, iOS simulator and iOS device with just the revert... so I was still trying to figure out the original need for the change. |
Try it with With this PR, the issue is fixed. This is especially relevant now that the current nightly sets the default
Can you elaborate on this? Is there a problem with linking to
I think that would work. |
Pinging @MichaelHills @mitchmindtree @simlay, please look into this when you get the time. There's a bit of time pressure here; again, this library doesn't link for macOS users using Rust I can make an updated PR with the changes described above (linking both AudioUnit and AudioToolbox for the |
Yes. You definitely know the space the best it seems. PS: Love your work with objc2 and such @madsmtm. |
So, I looked into it some more, and found that on macOS, AudioUnit exports the desired symbols in all versions (on newer versions they're just re-exports from AudioToolbox). On iOS, there is no AudioUnit to link to, so I've opened #51 (which builds upon this PR) but adds the required changes for iOS.
See my PR for more info on the linking; in short, yes, I'm at least like 90% sure, applications linking to AudioUnit still works like they always have, Apple has kept backwards compatibility there.
|
Actually, forget what I wrote about the order, I looked at the linked thread and that does seem like a real problem (even though I can't reproduce it because I don't have an old enough macOS version).
Thanks! |
Looks like this has been superceded by #51 which has landed, closing this. |
In response to #48 but need to do some testing