Does it fix all the weird linking issues?
1 Like
I’m going to take a look today but based on the solved issues I certainly hope so 
2 Likes
Looking forward to switching macOS/iOS development to the new MacBook!
Do you folks try out the betas or RCs before final release of each Xcode version?
In my previous job our business was a B2B framework for iOS and the only way we could have things working for customers on the day of Xcode release (which was often very close to the day new iOS versions were released 
) because Apple always break things was to try the betas and RCs as soon as available.
We had a separate CI pipeline where we could bump the Xcode version to check. It solved a lot of the pain early 
1 Like
@phraemer I did try the betas and I should have a branch with the changes I put in place at the time, I didn’t quite get to this yesterday, after I’ve got through the posts on the forum I was planning to spin it up and check.
We’re not quite there with CI such that we can just bump Xcode, I do like the idea of a separate pipeline for that.
3 Likes
It looks like 15.1 did not fix the problem?
according to release notes:
" Linking
Resolved Issues
- Fixed: Binaries using symbols with a weak definition crash at runtime on iOS 14/macOS 12 or older. This impacts primarily C++ projects due to their extensive use of weak symbols. (114813650) (FB13097713)
- Fixed: Weak symbol imports are linked as non-weak imports, when used from LTO object files. (115521975) (FB13171424)"
Does this mean it is no longer necessary to use -Wl -ld_classic to ensure builds targeting OS 10.13+ will run?
As far as I could tell all issues are resolved in 15.1.
There is no harm in continuing to use any of the workarounds for now. We didn’t want to force people to upgrade to Xcode 15.1 when they’ve only recently made the effort to move to 15.0, so you should be able to freely update to 15.1 without issue.
However, from now on anyone using any version of Xcode form 15.0 up to (but not including) 15.1, that isn’t enabling JUCE_SILENCE_XCODE_15_LINKER_WARNING will be faced with an error encouraging them to update their version of Xcode, instead of the previous detailed warning.
Once you have the above commit, and you’ve updated to Xcode 15.1 and you don’t plan on ever using older versions of Xcode 15, then you can remove the JUCE_SILENCE_XCODE_15_LINKER_WARNING preprocessor definition from your builds.
At some point in the future we may want to completely drop support for these versions of Xcode. If we do that we’ll likely add a warning when JUCE_SILENCE_XCODE_15_LINKER_WARNING is still enabled.
As for all the other workarounds I think it will have to be up to individuals to decide what they want to do, but as far as I can tell you should be able to remove all of them without harm, equally if the work arounds stay in place they also shouldn’t cause any harm.
3 Likes
…and while you are at it, you may also have a chance to devise a general approach to solve this FR, because what you mentioned above is basically exactly what was asked for: [FR] Emit warning when discontinued macro still defined
1 Like
Yeah I saw that FR I think it seems a very sensible request.
2 Likes