Fix dynamic linkage for ssl and curses#2
Closed
zimka wants to merge 1 commit into
Closed
Conversation
Owner
|
Thanks for the patch. I didn’t see it earlier. And have fixed it myself now. |
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.
Fix
import sslfailing in Glyphs 4 (broken OpenSSL dylib linkage)Hello! This PR fixes #1
It works locally, but if you think this issue should be resolve somehow else (e.g. without the fix_linkage.sh script) - feel free to cancel PR.
Related: Unable to load ssl module (Glyphs 3)
1) Change description
import sslfails in Glyphs 4 withLibrary not loaded: @rpath/Versions/3.14/lib/libssl.3.dylib, even though OpenSSL is bundled inPython.framework/Versions/3.14/lib/.This PR repoints bundled-lib dependencies on affected lib-dynload modules from
@rpath/Versions/3.14/lib/...to@loader_path/../../...(same pattern as Glyphs 3.11 for_ssl).Changes:
fix_linkage.sh— post-build step; can also patch an existing Plugin Manager installreadme.md— documents the step in the build pipeline_ssl,_curses,_curses_panel,_zstd2) Testing locally
1. Reproduce in Glyphs 4
Plugin Manager → install Python → Macro Panel:
Should fail before the fix; should succeed after.
2. Apply the fix
./fix_linkage.sh "$HOME/Library/Application Support/Glyphs 4/Repositories/Python"Restart Glyphs and run
import sslagain.3) Probable explanation
GlyphsPython 3.14 is built with relocatable-python, which rewrites links to bundled libraries under
Versions/3.14/lib/as@rpath/.... That assumes the host app has an rpath pointing at the framework.Glyphs installs Python under
~/Library/Application Support/Glyphs 4/Repositories/Python/, and Glyphs 4.app's rpaths do not include that path. dyld therefore fails to loadlibssl.3.dylibwhen_ssl.cpython-314-darwin.sois imported.Glyphs 3 fixed this for
_sslby switching to@loader_path/../../libssl.3.dylib, which resolves relative to the extension module itself. The 3.14 build omitted that step; the same@rpathissue also affects_curses,_curses_panel, and_zstd, which link other bundled libs inlib/.