Repository navigation
v1.9.418 — Mac DMG sidecar fix (PyInstaller libjli relocation)
Critical Mac-only fix. The signed v1.9.417 Mac DMG shipped a JVM that crashed at launch with SIGSEGV inside libjli's launcher code, so DOCX import via Okapi was broken on the macOS standalone. v1.9.418 fixes this by changing how the bundled JRE is added to the .app — see What changed below.
v1.9.417 Mac DMG users should upgrade. The Windows standalone and pip channels are unaffected.
Install
- Windows standalone: download
Supervertaler-v1.9.418-Windows.zipbelow, extract, double-clickSupervertaler.exe. For Start Menu integration, right-clickcreate_start_menu_shortcut.ps1→ Run with PowerShell. - macOS standalone (Apple Silicon only): download
Supervertaler-v1.9.418-macOS.dmgbelow, double-click to mount, dragSupervertaler.appto Applications, eject the DMG, launch from Applications. Signed and notarized — no Gatekeeper warnings, noxattrworkaround needed. - pip:
pip install --upgrade supervertaler
What changed (v1.9.418)
Fixed (CRITICAL: Mac standalone Okapi sidecar broken in v1.9.417)
The v1.9.417 Mac DMG's bundled java binary segfaulted immediately on launch. In-app log showed "hs_err_pid*.log) pointed at SIGSEGV at 0x0 inside libjli's launcher code.
Root cause: PyInstaller's macOS binary-relocation pass extracts libjli.dylib from inside the JRE tree out to Contents/Frameworks/libjli.dylib and rewrites its LC_LOAD_DYLIB and LC_RPATH commands. Meanwhile libjvm.dylib stays inside the JRE at its original path, untouched. Launcher (rewritten libjli) is then incompatible with VM (unmodified libjvm) — the JLI→JVM call dispatches into a null function pointer, JVM dies before initialising.
Fix: copy the bundled JRE into the .app after PyInstaller has finished, before code signing, instead of listing it in Supervertaler_macOS.spec's datas=. PyInstaller never sees the JRE, never relocates libjli, both launcher and VM stay paired with their original install_names. The existing signing pass picks up the JRE Mach-O binaries via find and signs them with the full JIT entitlements (cs.allow-jit, cs.allow-unsigned-executable-memory, cs.disable-library-validation) as before.
Two file changes:
Supervertaler_macOS.spec: drops the JRE entry fromdatas=(keeps the JAR).build_macos_signed.sh: post-PyInstallercp -Rof the JRE intoContents/Frameworks/okapi-sidecar/jre/, between the framework-fix step and code-signing.
Verified end-to-end on a freshly notarized v1.9.418 DMG: java -version returns openjdk version "17.0.18" cleanly (no segfault), Contents/Frameworks/libjli.dylib is gone, the JRE-internal libjli.dylib is present and signed.
Assets
Supervertaler-v1.9.418-Windows.zip— Windows standalone with bundled Okapi sidecar + JRE.Supervertaler-v1.9.418-macOS.dmg— Apple Silicon DMG, signed with Developer ID, notarized by Apple, stapled. Notarization submission ID:8ee2e196-79cf-424f-bf72-cce685089966.- pip wheel + sdist on PyPI: https://pypi.org/project/supervertaler/1.9.418/
For everything else recently shipped (Okapi-only DOCX import/export, faithful hyperlink round-trip, multi-file Okapi conversion, sidecar lifecycle hardening, progress dialogues, cell-select instrumentation, lazy-download for Windows + macOS pip users, Trados-aware Sidekick chat, AI Assistant attachment improvements, GitBook help link, the first signed Mac DMG attempt in v1.9.417), see the full release notes for v1.9.413.