Do we statically compile in extension modules?

[brettcannon]

I'm assuming not, but there might be reasons to that I'm not thinking of?

[indygreg]

For PBS, I statically linked so PyOxidizer could achieve single file executables.

Without that use case, dynamic linking makes more sense.

Especially on Linux, where the single symbol namespace of ELF can lead to problems when all extensions and their library dependencies are loaded at process start time.

So my vote is dynamic loading.

[geofft]

The broader Python ecosystem expects modules to not be statically linked in. We had to spin out _tkinter into a separate module to make matplotlib and PIL work, because they have code that uses _tkinter.__file__ as a way to get at the underlying Tcl/Tk library. In other words, the dlsym API (on all POSIX platforms, not just Linux!), and things on top of it like ctypes, is oriented around getting handles out of filenames, and while the argument that you should avoid __file__ is usually correct, there is no alternative for it for dynamic libraries.

We also ran into a problem recently where CPython 3.14's source code assumed that the _asyncio module was a separate file and so the fancy new asyncio remote debugging stuff didn't work. It turns out that CPython 3.15 now statically links that module, and I solved this by cherry-picking that patch (astral-sh/python-build-standalone#804). I think that's another argument that it's worth not diverging from upstream CPython's default build config.

[emmatyping]

Well, things here are upstream hopefully :)

But I agree not statically linking is preferable. Another issues is if we statically link libpython we also lose out on ctypes.pythonapi, which breaks a number of things unfortunately.

[cmaloney]

As additional data there is some performance tradeoff in doing dynamic, see: https://github.com/astral-sh/python-build-standalone/blob/bd5227106d439127be97530b7781ac933d849324/cpython-unix/patch-python-configure-add-enable-static-libpython-for-interpreter.patch#L12-L20 (although that doesn't have performance numbers in it).

(I think maximizing compatibility is reasonable to have high on the priority list for this; leave performance to others where can measure/tune/deploy more specialized)

[geofft]

Another issues is if we statically link libpython we also lose out on ctypes.pythonapi, which breaks a number of things unfortunately.

Seems to work for me, at least on GNU/Linux:

$ uvx python3.14
>>> import ctypes
>>> ctypes.pythonapi
<PyDLL 'None', handle 76fc3769f2e0 at 0x48284586490>
>>> ctypes.pythonapi.Py_BytesMain
<_FuncPtr object at 0x48284f60e10>
>>> import ctypes.util
>>> for i in ctypes.util.dllist(): print(i)
... 

linux-vdso.so.1
/lib/x86_64-linux-gnu/libpthread.so.0
/lib/x86_64-linux-gnu/libdl.so.2
/lib/x86_64-linux-gnu/libutil.so.1
/lib/x86_64-linux-gnu/librt.so.1
/lib/x86_64-linux-gnu/libm.so.6
/lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2

The main object (None) is a dynamic object itself and can export symbols, which is also how it's able to load extension modules.

I think the build should statically link libpython because there's a fairly noticeable performance impact in some cases (see python/cpython#133312), though now we get into an interesting question about whether to distribute the dynamic libpython too for the sake of embedders. python-build-standalone does, but for probably 90+% of our users it's a waste of space.

[brettcannon]

As additional data there is some performance tradeoff in doing dynamic

As stated in the README, being perf-oriented is a non-goal.

[zooba]

I don't think we need to statically link all our own extension modules, but I'd like to see their dependencies be statically linked (i.e. _ssl statically links OpenSSL). That way, the parts of resolution that are under our control are the ones that matter, and we aren't subject to (as much) interference from the OS.

[geofft]

FWIW, shipping those dependencies yourself (statically or dynamically) gets wacky in a couple of cases. For instance, Fedora's OpenSSL seems to have some patch that isn't upstream and an /etc/openssl/openssl.cnf that assumes that patch: astral-sh/uv#15327 You can ignore the system openssl.cnf, but that raises the question of whether it's appropriate to do that. If you dynamically link OpenSSL, then at least there is the option to force using the system's version. On the other hand, of course, you need the system to have a compatible version of OpenSSL

We are also discovering that apart from statically linking Tcl/Tk into tkinter being incompatible with the ecosystem (see above), merely shipping our own Tcl/Tk and libX11 and such means we're on the hook for shipping our own fonts and font renderer (astral-sh/python-build-standalone#740).

[indygreg]

The graphics stack to support tk was a constant burden to support. The dependency tree is non-trivial and I clearly missed several dependencies/features. Supporting tk is an outsized burden versus every other library dependency. If we could somehow jettison having to build/distribute it, that would save non-trivial maintenance effort.

[zooba]

I'm up for not distributing Tk.

If you dynamically link OpenSSL, then at least there is the option to force using the system's version.

I think we're not really looking for more options here ;) Users who want options have all the other ways of getting CPython - as lowest-common-denominator prebuilt binaries, "works and doesn't create/suffer interference" is the goal. Your system integrator (a.k.a. distro) will provide the most integrated version of CPython for your system.

[brettcannon]

I'm up for not distributing Tk.

Ditto, although I know it will make teachers sad due to the loss of turtle. I'm personally fine making Tk the last thing we worry about.

I think we're not really looking for more options here ;) Users who want options have all the other ways of getting CPython - as lowest-common-denominator prebuilt binaries, "works and doesn't create/suffer interference" is the goal. Your system integrator (a.k.a. distro) will provide the most integrated version of CPython for your system.

+1 to this.

[emmatyping]

Yeah, I was thinking we should start with the most minimal build possible (all optional modules off), then move on to adding zlib and openssl. Then build off of that incrementally/in parallel. I also expect Tcl/Tk to be the hardest and thus last item added