Closed mapierce closed 1 month ago
@mapierce Your PR adds a .debug.dylib
filename suffix to the search path, which I understand will lookup the dynamic library with debug symbols when running from Xcode via DEBUG build scheme... that is correct...
But what happens at runtime? Does the issue #1792 not happen at all when the app is archived in release mode?
@mman Correct it doesn't happen in release mode. ENABLE_DEBUG_DYLIB
being enabled only alters debug builds.
Fixing timeout in https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1810 before merging this PR
Is this ready for merge?
Hey @mtrezza seems I'm still getting a timeout on two jobs there. I have no ability to re-run them if you wouldn't mind
This is strange, because the job passed for https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1810 and I haven't found any other timeouts in actions. The timeout seems to be related to this PR, in which case we cannot merge it, because it increases the CI time >=5x. Any idea what may cause this?
@mapierce another PR has been opened with https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1811, any takeaways?
@mapierce How should we proceed with this PR?
New Pull Request Checklist
Issue Description
Closes: https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1792
Xcode 16 changes the default setting for Enable Debug Dylib Support to
YES
which adds a suffix of.debug.dylib
to the target at runtime meaning the standard call ofobjc_copyClassNamesForImage
with the image name will not find anything while the scheme is running in Debug mode.Approach
Adding the suffix based on the scheme build configuration fixes the issue to find the target at runtime and makes
objc_copyClassNamesForImage
work as expected.