Skip to content

Fix: Real libpython in the desktop jar, staged prefix and packaged home; extract into a cache - #85

Merged
b-re-w merged 7 commits into
developfrom
work/jar-libpython
Oct 3, 2026
Merged

b-re-w merged 7 commits into
developfrom
work/jar-libpython

Conversation

@b-re-w

@b-re-w b-re-w commented Oct 3, 2026

Copy link
Copy Markdown
Member

Closes #74

Defect fixed (SPEC L-9a)

  • python-build-standalone's libpython3.14.so is a symlink; Gradle's tarTree extracted it as a 0-byte file, so the desktop jar, the plugin's staged PYTHONHOME prefix and Desktop: ship the stdlib with a packaged app (jar/jpackage), not only via PYTHONHOME for Gradle tasks #60's packaged python-multiplatform-home all carried an empty library (toolchain#22 desktop-e2e: 'file too short'). The plugin now extracts the archive itself and materialises symlinks/hard links as copies of their targets (staging stamp bumped → old prefixes re-extract); the jar packs the real file under the loader's name; the packaged-home copy fails the build on any 0-byte libpython*.
  • The classpath library is extracted into a per-version user cache dir and reused, never the working directory.

Tests added: DesktopJarLibrariesTest, ExtractLibraryCacheTest, StagedPrefixLinksTest.

Verification (coordinator, after merging develop, each module separately): plugin 254/0, desktopTest 590/0, ksp artifact 35/0, app 70/0, compose 115/0, androidNative OK. Jar listing: lib/linux-x86_64/libpython3.14.so 251,884,016 bytes (was 0), no .so.1.0.

Not done: linux library ships unstripped from a macOS build host (no ELF strip) — follow-up issue.

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.

1 participant