Skip to content

Use sysconfigdata and build-details.json from shared library build#842

Merged
isuruf merged 7 commits into
conda-forge:devfrom
mgorny:ldlibrary-so
Feb 9, 2026
Merged

Use sysconfigdata and build-details.json from shared library build#842
isuruf merged 7 commits into
conda-forge:devfrom
mgorny:ldlibrary-so

Conversation

@mgorny

@mgorny mgorny commented Jan 15, 2026

Copy link
Copy Markdown
Contributor

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

Use the sysconfigdata from the shared library build rather than the static one. The main difference is that this ensures that programs link to the shared Python library rather than the static library. Other differences are mostly superficial (build directories, test invocation commands).

Also use the build-details.json from there. Unlike the static build version, it has all the data, including static and shared library, and extension build details.

Fixes #565

@conda-forge-admin

conda-forge-admin commented Jan 15, 2026

Copy link
Copy Markdown
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 (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

  • ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
  • ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21262143921. Examine the logs at this URL for more detail.

@mgorny

mgorny commented Jan 16, 2026

Copy link
Copy Markdown
Contributor Author

Okay, so:

  1. Looks like my change is also causing python3-config --ldflags --embed to link against the dynamic library, which seems reasonable. However, tests need updating for that.
  2. Given Move libpython.so to another output #843, perhaps instead of trying to force shared/static from a single test, I'll just split the libraries and test each one separately.

@mgorny

mgorny commented Jan 16, 2026

Copy link
Copy Markdown
Contributor Author

Oh wait, that's for 3.15+ only.

@mgorny

mgorny commented Jan 16, 2026

Copy link
Copy Markdown
Contributor Author

Ok, it's green now.

Comment thread recipe/meta.yaml
requires:
- {{ stdlib('c') }}
- {{ compiler('c') }}
- ripgrep

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leftover from debugging?

@mgorny mgorny Jan 16, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's actually used in tests. However, it was listed only for python output and was missing for libpython-static.

@isuruf isuruf left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is gonna make recipes like uWSGI link to the shared python library instead of the static library from a build number bump.

@mgorny

mgorny commented Jan 17, 2026

Copy link
Copy Markdown
Contributor Author

This is gonna make recipes like uWSGI link to the shared python library instead of the static library from a build number bump.

What's your suggestion?

@isuruf

isuruf commented Jan 20, 2026

Copy link
Copy Markdown
Member

We can merge this to the dev branch along with a solution to #843 and make it the default for 3.15.

@rgommers

rgommers commented Jan 21, 2026

Copy link
Copy Markdown

@isuruf if the problem can only be fixed properly for 3.15, can build-details.json at least be patched up? It's currently just broken (e.g., https://peps.python.org/pep-0739/#libpython-link-extensions is missing); it's new in Python 3.14 and quite useful when working on cross-compilation. And surely that would be fully backwards compatible (I mean, no project in conda-forge like uWSGI will be relying on it).

@mgorny

mgorny commented Jan 21, 2026

Copy link
Copy Markdown
Contributor Author

How about using an explicit migrator to switch all versions? I suppose that would involve a lot of rebuilding, a large part of it not strictly necessary.

Use the sysconfigdata from the shared library build rather than the
static one. The main difference is that this ensures that programs link
to the shared Python library rather than the static library. Other
differences are mostly superficial (build directories, test invocation
commands).

Fixes conda-forge#565

Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Now python3-config defaults to shared linking, so perform that part of
the test first.  Then remove the shared libraries to force static
linking.

Signed-off-by: Michał Górny <mgorny@quansight.com>
…6.01.20.09.33.33

Other tools:
- conda-build 25.11.1
- rattler-build 0.55.0
- rattler-build-conda-compat 1.4.10
@mgorny mgorny changed the base branch from main to dev January 21, 2026 15:47
@isuruf

isuruf commented Jan 21, 2026

Copy link
Copy Markdown
Member

@isuruf if the problem can only be fixed properly for 3.15, can build-details.json at least be patched up?

Sure. That's okay.

How about using an explicit migrator to switch all versions?

I'm not sure what you mean by here. Migrator for all downstream python packages?

@mgorny

mgorny commented Jan 21, 2026

Copy link
Copy Markdown
Contributor Author

How about using an explicit migrator to switch all versions?

I'm not sure what you mean by here. Migrator for all downstream python packages?

I'm not sure if I understand migrators correctly, but my thinking would be pinning to current python versions for all slots with "static build" default, and using a migrator to migrate to "shared build" default.

@mgorny

mgorny commented Jan 21, 2026

Copy link
Copy Markdown
Contributor Author

Either way, rebased on dev to get the initial change in, and I'm working on libpython-devel now.

@mgorny

mgorny commented Jan 21, 2026

Copy link
Copy Markdown
Contributor Author

(I'm assuming we still want python to install the minimum amount of development files required to build Python extensions, so pip install ... remains fully working.)

@isuruf

isuruf commented Jan 21, 2026

Copy link
Copy Markdown
Member

Yes, we can move libpython.so to libpython and keep everything else in python as it is. Then users can install libpython or libpython-static if they want to embed python.

@isuruf

isuruf commented Jan 21, 2026

Copy link
Copy Markdown
Member

I'm not sure if I understand migrators correctly, but my thinking would be pinning to current python versions for all slots with "static build" default, and using a migrator to migrate to "shared build" default.

We could, but there are many users of the python package outside of conda-forge, and I really don't want to break them. (There's definitely less users of libpython-static, but can't be sure of its users)

@mgorny

mgorny commented Jan 21, 2026

Copy link
Copy Markdown
Contributor Author

Then users can install libpython or libpython-static if they want to embed python.

In #843, you said libpython-devel with both shared and static library. Am I following the wrong path?

@isuruf

isuruf commented Jan 21, 2026

Copy link
Copy Markdown
Member

In #843, you said libpython-devel with both shared and static library. Am I following the wrong path?

We can't have the two together right? Looking at this PR and the tests, we have to manually delete the other if both exist.

@mgorny

mgorny commented Jan 21, 2026

Copy link
Copy Markdown
Contributor Author

In #843, you said libpython-devel with both shared and static library. Am I following the wrong path?

We can't have the two together right? Looking at this PR and the tests, we have to manually delete the other if both exist.

Only for -lpythonX.Y to work with no extra effort. At least on Linux, -Bstatic and -Bdynamic let's you choose; I couldn't find anything for macOS. At least build-details.json has paths to both libraries, and I suspect CMake and Meson have their own lookup logic that handles both.

@isuruf

isuruf commented Jan 21, 2026

Copy link
Copy Markdown
Member

Only for -lpythonX.Y to work with no extra effort.

People generally use python3-config --embed which should work properly.

@mgorny

mgorny commented Jan 22, 2026

Copy link
Copy Markdown
Contributor Author

Looks like almost all failed on package output verification, with the exception of macOS that failed on cp options. I have a fix ready, but I'll wait with pushing till conda-forge/admin-requests#1854 is merged, so we could get clearer CI results.

@mgorny

mgorny commented Jan 22, 2026

Copy link
Copy Markdown
Contributor Author

I've just noticed that I didn't do libpython*.so symlink correctly; working on fixing that now. Apparently the build directory doesn't use symlinks at all, and they're added in bininstall target.

Fixes conda-forge#843

Signed-off-by: Michał Górny <mgorny@quansight.com>
…6.01.22.10.05.09

Other tools:
- conda-build 25.11.1
- rattler-build 0.55.0
- rattler-build-conda-compat 1.4.10
@mgorny

mgorny commented Feb 7, 2026

Copy link
Copy Markdown
Contributor Author

@isuruf, I think this one's ready, right?

mgorny added a commit to mgorny/python-feedstock that referenced this pull request Feb 9, 2026
Install `build-details.json` from shared library build rather than the
static build, as the latter does not include the data needed to build
extensions, and therefore it is not useful for cross-compilation.
This is backported from conda-forge#842, but unlike that PR it should not break
anything.

Signed-off-by: Michał Górny <mgorny@quansight.com>
@mgorny

mgorny commented Feb 9, 2026

Copy link
Copy Markdown
Contributor Author

Filed #858 for 3.14.

@isuruf isuruf merged commit b703e4d into conda-forge:dev Feb 9, 2026
25 checks passed
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.

LDLIBRARY is set to libpython3.9a although no static lib is included in mambaforge for Linux

4 participants