add run-export to libpython - #928
Merged
Merged
Conversation
h-vetinari
requested review from
chrisburr,
isuruf,
jakirkham,
katietz,
mbargull,
msarahan,
ocefpaf,
pelson,
scopatz and
xhochy
as code owners
September 7, 2026 10:39
Contributor
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe/meta.yaml:
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/35135282846. Examine the logs at this URL for more detail. |
Member
Author
|
Ping @isuruf |
isuruf
reviewed
Sep 14, 2026
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
Member
Author
|
@conda-forge-admin, please relint |
Member
Author
|
committed your suggestion; PTAL :) |
isuruf
reviewed
Sep 16, 2026
Contributor
|
Hi! This is the friendly conda-forge automerge bot! Commits were made to this PR after the |
Member
|
Thanks |
chrisburr
added a commit
to conda-forge/root-feedstock
that referenced
this pull request
Sep 18, 2026
Same defect as on main, backported for consistency: the build enables -Dtpython=ON and -Dtmva-pymva=ON, and both libROOTTPython and libPyMVA link Python3::Python - an embedded CPython, not the extension-module ABI. The osx-only TPython patch rewires one of the two, so libpython is linked on every platform. Today this branch only builds 3.11-3.14, where the python package still depends on libpython and drags it in transitively, so this is a declaration fix that silences the overlinking warning rather than a functional change. It becomes load-bearing the moment 3.15 is added, since python 3.15 drops that dependency (conda-forge/python-feedstock#894). Listed in both host and run because libpython only gained a run-export on the 3.15 branch (conda-forge/python-feedstock#928). Not a pinned variant key, so no rerender is needed for it.
chrisburr
added a commit
to conda-forge/root-feedstock
that referenced
this pull request
Sep 18, 2026
Same defect as on main, backported for consistency: the build enables -Dtpython=ON and -Dtmva-pymva=ON, and both libROOTTPython and libPyMVA link Python3::Python - an embedded CPython, not the extension-module ABI. The osx-only TPython patch rewires one of the two, so libpython is linked on every platform. Today this branch only builds 3.11-3.14, where the python package still depends on libpython and drags it in transitively, so this is a declaration fix that silences the overlinking warning rather than a functional change. It becomes load-bearing the moment 3.15 is added, since python 3.15 drops that dependency (conda-forge/python-feedstock#894). Listed in both host and run because libpython only gained a run-export on the 3.15 branch (conda-forge/python-feedstock#928). Not a pinned variant key, so no rerender is needed for it.
Member
|
Can you send backport PRs? |
conda-forge-admin
pushed a commit
to conda-forge/root-feedstock
that referenced
this pull request
Sep 19, 2026
The conda build enables -Dtpython=ON and -Dtmva-pymva=ON, and both
libROOTTPython and libPyMVA link Python3::Python, i.e. an embedded
CPython rather than the extension-module ABI. Patch 0004 rewires only
TPython, and only on osx, so libpython is linked on every platform.
The 6.40.04 build already reports this:
warning Overlinking against "lib/libpython3.12.so.1.0" for
"lib/libROOTTPython.so.6.40.04"
warning Overlinking against "lib/libpython3.12.so.1.0" for
"lib/libPyMVA.so.6.40.04"
Up to 3.14 it was only a declaration problem, because the python package
depends on libpython and so dragged it in transitively. From 3.15 the
python package drops that dependency entirely
(conda-forge/python-feedstock#894), so libpython would be absent from the
host environment and find_package(Python3 COMPONENTS Development) would
fail at configure time.
Listed in both host and run: libpython only gained a run-export on the
3.15 branch (conda-forge/python-feedstock#928), so host alone is not
enough for 3.11-3.14. libpython is not a pinned variant key, so this
needs no rerender on its own.
Verified with a render; the linking result is left to CI.
This was referenced Sep 20, 2026
Member
Author
Done. |
skupr-anaconda
added a commit
to AnacondaRecipes/python-feedstock
that referenced
this pull request
Sep 21, 2026
Replay #256 topology on origin/master without merge 2a73320. Keep master patch numbering (0028 site.pth, 0029 zlib-ng, 0030 xxlimited). Wrap win FT patches in freethreading jinja; add CF conda-forge#928 libpython unix weak run_exports. Refs: PKG-15601
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
3 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.
For users of
libpythonlikelldb, we should IMO indicate the dependence with ahost:dependence as usual, and then inherit the run-export, also as usual. For py<315 this is less relevant (except for the link check), but for 3.15+, wherelibpython3.{so,dylib}is not part of thepythonpackage anymore, this would make sense IMO.If/once merged, it would also be reasonable to backport this to past python versions IMO, if only for consistency (and again the link check).