Tags: astral-sh/python-build-standalone
Tags
Disable unsafe identical code folding in BOLT (#622) astral-sh/uv#13610 reported a misbehavior that is the result of a subclass of str incorrectly having its ->tp_as_number->nb_add slot filled in with the value of PyUnicode_Type->tp_as_sequence->sq_concat. There are some times when this is an appropriate thing to do iwhen subclassing, but this is not one of them. The logic to prevent it in this case relies on two helper functions in the file, wrap_binaryfunc and wrap_binaryfunc_l, having different addresses, even though they contain identical code. For some reason BOLT does not do this optimization in the shared library (even though those are static functions and not exported), so we only started seeing this in the static build. BOLT in LLVM 20+ supports "safe" code folding, which uses heuristics about relocations to determine whether a function's address is used in any way other than a call. This seems to be enough to fix the issue. Add a patch to switch to -icf=safe, submitted upstream as python/cpython#134642
Add an rpath to bin/python3 on glibc platforms to fix #619 (#621) Even though the Python interpreter no longer needs libpython3.x.so, it turns out some extension modules (incorrectly) do, and miraculously, allowing them to find libpython3.x.so doesn't actually break things, for reasons detailed in the comment. So set an rpath that allows libpython3.x.so to be loaded if needed by some other library, even though we won't use that ourselves. We are already doing this on musl; do it on glibc too. Note that this change does not risk users who want to make bin/python3 setuid or setcap (e.g. #576); while the rpath is presumably ignored for privileged binaries, there is no error message, and the binary launches fine, and _because_ we do not need the rpath in order for the interpreter to work, everything (except these misbuilt extension modules) works.
Declare the `target_cxx` value for all targets (#563) This value can leak into user builds through sysconfig so it is not appropriate to use the `host_cxx`. See astral-sh/uv#12207 There's not a `musl-clang++` equivalent — so we skip this for those targets.
Add dynamically linked musl distributions (#541) 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.
PreviousNext