Skip to content

Fix dynamic linkage for ssl and curses#2

Closed
zimka wants to merge 1 commit into
schriftgestalt:mainfrom
zimka:fix/dynload-loader-path
Closed

Fix dynamic linkage for ssl and curses#2
zimka wants to merge 1 commit into
schriftgestalt:mainfrom
zimka:fix/dynload-loader-path

Conversation

@zimka

@zimka zimka commented Jul 2, 2026

Copy link
Copy Markdown

Fix import ssl failing 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 ssl fails in Glyphs 4 with Library not loaded: @rpath/Versions/3.14/lib/libssl.3.dylib, even though OpenSSL is bundled in Python.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 install
  • readme.md — documents the step in the build pipeline
  • Updated binaries: _ssl, _curses, _curses_panel, _zstd

2) Testing locally

1. Reproduce in Glyphs 4

Plugin Manager → install Python → Macro Panel:

import ssl

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 ssl again.


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 load libssl.3.dylib when _ssl.cpython-314-darwin.so is imported.

Glyphs 3 fixed this for _ssl by switching to @loader_path/../../libssl.3.dylib, which resolves relative to the extension module itself. The 3.14 build omitted that step; the same @rpath issue also affects _curses, _curses_panel, and _zstd, which link other bundled libs in lib/.

@schriftgestalt

Copy link
Copy Markdown
Owner

Thanks for the patch. I didn’t see it earlier. And have fixed it myself now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SSL and curses import fail in Glyphs 4

2 participants