build(before-code-freeze): Export the stub's dynamic symbols when libpython is static (#451) - #453
Merged
mc-nv merged 1 commit intoSep 2, 2026
Conversation
…python is static (#451) * build: Export the stub's dynamic symbols when libpython is static The manylinux base container builds CPython with --disable-shared, so on that platform triton_python_backend_stub links libpython3.x.a and the Py_* symbols live in the executable rather than a shared library. Python C extension modules are dlopen'ed and deliberately leave Py_* undefined -- every one of the 77 lib-dynload modules in the image does, math.so alone with 63 undefined symbols and no libpython in DT_NEEDED -- so they can only bind against the stub's dynamic symbol table. Without the export the stub links and starts, then fails on the first `import math`. Set ENABLE_EXPORTS, which makes CMake add the platform's flag (-Wl,--export-dynamic on Linux, per Platform/Linux.cmake), matching how CPython links its own interpreter. Gate it on the resolved library being an archive rather than on the platform. A shared libpython needs no export, so the Debian build is unaffected, and the condition stays correct if a target moves between the two linkage modes. The condition reads PYTHON_LIBRARY, not PYTHON_LIBRARIES: pybind11 arrives through FetchContent_MakeAvailable, which uses add_subdirectory, so only the cache entry find_library creates crosses back into this scope. PYTHON_LIBRARIES is a plain variable in pybind11's directory and is empty here, which would have made this a silent no-op. * docs: Correct the stale RHEL_BUILD rationale The comment said RHEL_BUILD existed because pybind would otherwise pick up Python 3.6 in the RHEL base container, so PYBIND11_PYTHON_VERSION was set to force 3.12. That pin has been dropped from build.py -- pybind11 prefers the newest entry of its own Python_ADDITIONAL_VERSIONS list, and the manylinux base container puts a single interpreter first on PATH. RHEL_BUILD itself stays: it still selects the stub's link settings further down. Only the justification was wrong. (cherry picked from commit 96d6021)
This was referenced Sep 1, 2026
Merged
mc-nv
added
build
mc-nv
marked this pull request as ready for review
September 1, 2026 19:19
Greptile SummaryThis PR conditionally exports symbols from the Python backend stub when it links against a static libpython, allowing dynamically loaded Python extension modules to resolve
Confidence Score: 5/5The PR appears safe to merge, with the export behavior narrowly limited to static-libpython builds. The new condition enables executable symbol exports for the stub only when Python discovery resolves an archive, while shared-library builds retain their existing linkage behavior. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
C[CMake config] --> D{PYTHON_LIBRARY ends in .a?}
D -- Yes --> E[Enable executable exports]
E --> S[Stub dynamic symbol table exposes Py_*]
S --> M[dlopen'ed extension modules resolve Python symbols]
D -- No --> L[Use shared libpython for symbol resolution]
Reviews (1): Last reviewed commit: "build(before-code-freeze): Export the st..." | Re-trigger Greptile |
yinggeh
approved these changes
Sep 1, 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
2 participants
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.
What does the PR do?
r26.08ontomain.--disable-shared, soPy_*symbols live in the stub executable; extension modules are dlopen'ed and can only bind against its dynamic symbol table.Checklist
<commit_type>: <Title>Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Related PRs:
Where should the reviewer start?
CMakeLists.txt— theENABLE_EXPORTScondition.Test plan:
Full CI run on the internal pipeline at
TRITON_CONTAINER_VERSION=26.09dev_user, withTRITON_NIGHTLY=1andTRITON_SBSA=1.Local verification: per-repo
pre-commit run --files <changed>passes with no auto-fixes.CI Pipeline ID:
Caveats:
TRITON_SERVER_MODEL_REPO_VERSIONderives fromTRITON_CONTAINER_VERSION, so26.09devmust exist on the share first.Background
Post-release step of the 26.08 train: the default branches move onto the same upstream containers as the just-released
r26.08, and pick up the fixes that landed only on the release branch while it stabilised.Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)