fix(zipapp): store _solib shared libraries as files, not absolute symlinks - #4211
Merged
rickeylev merged 1 commit intoOct 5, 2026
Merged
Conversation
…links Since bazel-contrib#4165, the zipper keeps a symlink for an input whose original source is a symlink, looking through the absolute symlink the Bazel sandbox exposes the input as. For the `_solib` entries Bazel creates for shared libraries, the original source is itself an absolute symlink into the build machine's output base, so the zipapp stored entries like runfiles/_main/_solib_x86_64/libST-..._Slibgrpc.so -> /home/<user>/.cache/bazel/<hash>/execroot/_main/bazel-out/.../libgrpc.so which dangle on any other machine. Any zipapp whose Python code loads a shared library from `_solib` (a C extension that links a `cc_library` dynamically, or `libpython` for an extension that links it) fails to load it outside the machine that built it. Before bazel-contrib#4165 these files were copied. To fix, only keep the looked-through target when it is relative, e.g. `libpython3.10.so -> libpython3.10.so.1.0` inside the runtime, which is what the size optimization in bazel-contrib#4165 is for. Otherwise the file is stored. * Adds a zipper test with the `_solib` shape: a sandbox symlink to an absolute symlink to the library. It fails without the fix ("should NOT be a symlink but is").
Contributor
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused implementation correctly addresses the portability bug and includes appropriate regression coverage.
Review effort: Balanced
Findings: None
What changed in this PR
Fixes non-portable zipapps by copying absolute _solib symlink targets instead of preserving machine-local links—a decidedly less silly walk.
Changes:
- Preserves only relative source symlinks.
- Adds regression coverage for sandboxed
_soliblinks. - Documents the user-visible fix.
| File | Description |
|---|---|
tools/zipapp/zipper.py |
Copies targets of absolute source symlinks. |
tests/tools/zipapp/zipper_test.py |
Tests the _solib sandbox shape. |
news/zipapp-absolute-source-symlinks.fixed.md |
Adds the release note. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
rickeylev
approved these changes
Oct 5, 2026
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.
Since #4165, the zipper keeps a symlink for an input whose original source is a
symlink, looking through the absolute symlink the Bazel sandbox exposes the
input as. For the
_solibentries Bazel creates for shared libraries, theoriginal source is itself an absolute symlink into the build machine's output
base, so the zipapp stored entries like
which dangle on any other machine. Any zipapp whose Python code loads a shared
library from
_solib(a C extension that links acc_librarydynamically, orlibpythonfor an extension that links it) fails to load it outside themachine that built it. Before #4165 these files were copied.
To fix, only keep the looked-through target when it is relative, e.g.
libpython3.10.so -> libpython3.10.so.1.0inside the runtime, which is whatthe size optimization in #4165 is for. Otherwise the file is stored.
_solibshape: a sandbox symlink to an absolutesymlink to the library. It fails without the fix ("should NOT be a symlink
but is").