Refactor static / dynamic linking into build options#546
Closed
Refactor static / dynamic linking into build options#546
Conversation
zanieb
force-pushed
the
zb/ref-static
branch
from
7502b0d to
eb8c67a
Compare
zanieb
force-pushed
the
zb/ref-static
branch
from
eb8c67a to
23a92fd
Compare
Member
Author
|
After trying #547 I think this is a little simpler because we otherwise have to sanitize all the targets when building packages, e.g., |
zanieb
commented
Mar 5, 2025
cpython-unix/build-main.py
Outdated
Comment on lines
+58
to
+65
| # Construct possible options, we use a set here for canonical ordering | ||
| options = set() | ||
| options.update({"debug", "noopt", "pgo", "lto", "pgo+lto"}) | ||
| options.update({f"freethreaded+{option}" for option in options}) | ||
| link_modes = {"static", "shared"} | ||
| options.update( | ||
| {f"{option}+{link_mode}" for link_mode in link_modes for option in options} | ||
| ) |
Member
Author
There was a problem hiding this comment.
I don't like this, especially since it's repeated. I will refactor this further separately.
Member
Author
|
Some history on shared / static fields can be found by following #241 |
zanieb
added a commit
that referenced
this pull request
Mar 11, 2025
As a consequence of #540 I was playing with these concepts and decided to explore it. This includes #546 (could be merged separately or together), which separates "static" builds from the "musl" triple specifically in favor of a dedicated build option. The main implementation downside here is that `$ORIGIN` doesn't work with DT_NEEDED so we need to use RUNPATH instead, which can cause the wrong library to be loaded if LD_LIBRARY_PATH is set. Given the current builds aren't usable at all, I think this is a fine trade-off. We can explore alternatives in the future, like statically linking just libpython. Another caveat here: for consistency with the glibc builds, we're changing the "default" musl build to be dynamically linked. This is a breaking change in the release artifacts. The statically linked musl build will include a `+static` suffix. We could do something for backwards compatibility here, but I _think_ this probably makes sense in the long term. My primary concern is that consumers that combine releases (such as uv) would need to encode this change (e.g., toggle the expectation based on the python-build-standalone version tag). It's challenging to test changes to the release artifact handling. Regardless of approach, this will need a follow-up to adjust that accordingly.
Member
Author
|
Merged via #541 |
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
1 participant
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.
A bit on the fence about where to put this, i.e., it could be a part of the target triple? Trying this out to start.
The goal here is to untangle the static vs shared builds from musl per #542 so we can ship both kinds in #541