Geoffrey Thomas

It's totally fine if you want to decide to stop using the internal build and just use the .debs from here! The git history is kind of confusing. I think...

Can you please confirm whether the dates you listed under "Timeline" are accurate? Was this issue first originally identified on June 13, 2025?

This is _extremely_ rough, probably misbehaves on Windows, and is probably incomplete in some interesting way. I think it also misbehaves with Python 3.14. All I can say is it...

What do you need out of python-build-standalone to make it suitable for PyInstaller? I'm working on making it less unusual / more compatible, and I'd like to avoid you needing...

Is it that you want a program using libpython to be able to `import tkinter` without fiddling with rpaths? I can fix that for glibc and orobably musl. I expect...

OK, I can change that! Is it okay if I give tkinter a `DT_RPATH` of `${ORIGIN]/../..` _and_ a `DT_NEEDED` of `${ORIGIN]/../../libtcl8.6.so` and `${ORIGIN}/../../libtk8.6.so`? If you're just looking at `ldd` output...

> Splitting out the other extensions from libpython.so would be the main thing. PyInstaller aims to exclude extensions that the user doesn't need and it can't do that if they're...

If you want to play around with it, the GHA downloads at https://github.com/astral-sh/python-build-standalone/actions/runs/16888548665?pr=745 e.g. [cpython-3.9-x86_64-unknown-linux-gnu-pgo+lto](https://github.com/astral-sh/python-build-standalone/actions/runs/16888548665/artifacts/3737712358) should have the change itself: ``` $ tar xf cpython-3.9.23-x86_64-unknown-linux-gnu-pgo+lto-20250811T1819.tar.zst python/install/ $ ldd python/install/lib/python3.9/lib-dynload/_tkinter.cpython-39-x86_64-linux-gnu.so linux-vdso.so.1...

Internal change to switch to Node 18: https://tsdev.app.twosigma.com/pr/cr39679