statically link libpython on macOS

[jjhelmus]

Statically link python to libpython on macOS.

A dynamic libpython is still built and included in the distribution for embedded use.

Remove patches that disable linking the libraries in statically linked Python stdlib modules to python as these are now needed.

closes #636

[jjhelmus]

Closing + reopening to (hopefully) re-trigger CI

[geofft]

Well this seems fine but now I'm wondering what the linker issue was last time around. Fine with me to merge but I might try to remember what the issue was if I get a chance.

[jjhelmus]

#636 mentions linker errors of:

cpython-3.14> ld64.lld: error: undefined symbol: BZ2_bzDecompress
cpython-3.14> ld64.lld: error: undefined symbol: ffi_prep_closure_loc
cpython-3.14> ld64.lld: error: undefined symbol: Tcl_FindExecutable

Was this is issue that was refer to in the comment?

The first two I did encounter when including --enable-static-libpython-for-interpreter but not removing the patches. The Tcl symbol is no longer necessary as _tkinter is built dynamically.

Removing the patches added re-introduces $(MODLIBS) to the link command so -Xlinker -hidden-lbz2 -Xlinker -hidden-lffi -Xlinker ... are included which resolves the undefined symbol issue.

[geofft]

That sounds about right and makes sense.

[jjhelmus]

I was curious if this change has an effect on performance so I ran fastmark on the 3.13 releases from 20260414 (dynamically linked) and 20260504 (statically linked). The results from averaging 5 runs are:

20260414 (dynamically linked) : 26,485
20260504 (statically linked) : 26,416

The difference between these two is not statically significant so it seems that on macOS statically linking makes little difference, although individual benchmarks may see more benefit. Additionally the free-threaded build was not tested which may benefit from TLS when statically linked.