Repository navigation
fix(release): add @executable_path rpath so the app finds Sparkle - #71
Merged
Merged
Conversation
v0.1.6 built via xcodebuild aborted at launch with a DYLD error
("Library not loaded: @rpath/Sparkle.framework/Versions/B/Sparkle").
The binary links Sparkle as @rpath/Sparkle.framework, but xcodebuild's
only relocatable rpath is @executable_path/../lib (→ Contents/lib),
while make-app-bundle embeds Sparkle at Contents/MacOS. dyld therefore
looked in Contents/lib and found nothing.
Add a plain @executable_path rpath (= Contents/MacOS) to the binary so
@rpath resolves to the embedded framework. Only added when the exact
entry is absent (install_name_tool errors on a duplicate; swift build
binaries already resolve it), and before signing since it invalidates
the signature.
Verified locally against the published v0.1.6 products: the app now
launches and stays running with no DYLD abort.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
v0.1.6 (built via the new xcodebuild path) still crashed at launch —
but with a different, clearer fault than the v0.1.5
Bundle.modulecrash (which is now fixed). The new crash:
The binary links Sparkle as
@rpath/Sparkle.framework. xcodebuild givesthe binary only
@executable_path/../libas a relocatable rpath (→Contents/lib), butmake-app-bundle.shembedsSparkle.frameworkinContents/MacOS. So@rpathnever resolved to the embedded framework.(
swift buildbinaries carry an rpath that already resolves toContents/MacOS, which is why dev builds launched.)Fix
Add a plain
@executable_pathrpath (=Contents/MacOS) to the binaryin
make-app-bundle.sh, so@rpath/Sparkle.frameworkfinds the embeddedcopy. Only added when the exact entry is absent (
install_name_toolerrors on a duplicate;
swift buildbinaries already have a workingrpath), and before signing since it invalidates the signature.
Verification (local, against the real published v0.1.6 products)
Simpleton-0.1.6.zip.new crash report.
make-app-bundle.shend-to-end against areconstructed products dir → produced app launches clean.
shellcheckclean; rpath guard correctly detects present/absent.