Skip to content

v1.9.418 — Mac DMG sidecar fix (PyInstaller libjli relocation)

Choose a tag to compare

@michaelbeijer michaelbeijer released this 04 May 17:58
· 571 commits to main since this release

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.zip below, extract, double-click Supervertaler.exe. For Start Menu integration, right-click create_start_menu_shortcut.ps1 → Run with PowerShell.
  • macOS standalone (Apple Silicon only): download Supervertaler-v1.9.418-macOS.dmg below, double-click to mount, drag Supervertaler.app to Applications, eject the DMG, launch from Applications. Signed and notarized — no Gatekeeper warnings, no xattr workaround 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 "⚠️ Okapi sidecar failed to start – using built-in filters" on every startup. Crash dump (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 from datas= (keeps the JAR).
  • build_macos_signed.sh: post-PyInstaller cp -R of the JRE into Contents/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.