Python wheels for 3.13t and 3.14t

[marcelotduarte]

Hi! Do you plan to make wheels available for Python 3.13t and 3.14t?

[ngoldbaum]

Hi! I'm one of the main authors of https://py-free-threading.github.io and am happy to answer questions about getting support for the free-threaded build set up.

This library is a build dependency of llvmlite and I'm keen to get llvmlite unblocked, since that's needed to release a version of numba on the free-threaded build.

[ngoldbaum]

I'm able to build the Python bindings using 3.14.0t if I update the build dependencies:

diff --git a/api/python/build-requirements.txt b/api/python/build-requirements.txt
index 729d9c97..c9f98fb6 100644
--- a/api/python/build-requirements.txt
+++ b/api/python/build-requirements.txt
@@ -1,10 +1,10 @@
-tomli==2.2.1
-scikit-build-core==0.11.1
+tomli==2.3.0
+scikit-build-core==0.11.6
 # For Ninja: msvc.msvc14_get_vc_env
 setuptools==70.2.0
 # For the "env" feature
-pydantic==2.11.3
+pydantic==2.12.3
 # Implicit from scikit-build-core
 pathspec==0.12.1
-build==1.2.1
+build==1.3.0
 wheel==0.45.1

I'm then able to run the tests and see one failure (which I think is unrelated - I also see it on the GIL-enabled build):

======================================================================================== FAILURES ========================================================================================
____________________________________________________________________________________ test_issue_1251 _____________________________________________________________________________________

    def test_issue_1251():
>       elf = lief.ELF.parse(get_sample("ELF/libmmkv.so"))

tests/elf/test_builder.py:487:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

filename = 'ELF/libmmkv.so'

    def get_sample(filename):
        fullpath = os.path.join(lief_samples_dir(), filename)

>       assert os.path.exists(fullpath)
E       AssertionError

tests/utils.py:42: AssertionError
==================================================================================== warnings summary ====================================================================================
tests/api/test_python_bindings.py::test_invalid_enum
  /Users/goldbaum/Documents/LIEF/tests/api/test_python_bindings.py:23: RuntimeWarning: 2 is not a valid VERSION.
    lief.ELF.Header.VERSION.from_value(2)

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
================================================================================ short test summary info =================================================================================
FAILED tests/elf/test_builder.py::test_issue_1251 - AssertionError
================================================================= 1 failed, 466 passed, 112 skipped, 1 warning in 17.12s =================================================================

However, when pytest exits, I also see a ton of error output from nanobind about leaked instances and types: https://gist.github.com/ngoldbaum/9ca07edf0e9be48ddb349aaf6682c03a

[romainthomas]

Hi!
Free-threaded should compile correctly as you did @ngoldbaum but LIEF main API is not thread safe which means (if I'm not wrong) that the bindings should manage all the mutex and the threading sync.

[ngoldbaum]

but LIEF main API is not thread safe which means (if I'm not wrong) that the bindings should manage all the mutex and the threading sync

That's true, but I think is an orthogonal point to the question of whether you should support the free-threaded build.

I think even having wheels on PyPI that re-enable the GIL would be very useful. For my purposes, that would unlock shipping llvmlite free-threaded wheels without adding a bunch of hacks: numba/llvmlite#1351

While it may be possible to trigger new kinds of thread safety issues on the free-threaded build, if the bindings themselves don't account for the thread safety of the C++ library and then C++ library is unsafe, then it's almost certainly possible to break things on the GIL-enabled build using the threading module.

It's also perfectly valid to ship thread-unsafe code but IMO you should clearly document what the limitations are. Runtime crashes can always turn into exceptions or running code in the future with work to improve the thread safety of the bindings.

FWIW, I'm able to relatively easily trigger deadlocks by running the tests in the PyLIEF test suite in a thread pool under pytest-run-parallel using the GIL-enabled build and the following change to the test runner script:

diff --git a/tests/run_pytest.py b/tests/run_pytest.py
index d458d71e..b3027a3c 100644
--- a/tests/run_pytest.py
+++ b/tests/run_pytest.py
@@ -25,7 +25,8 @@ def run(junit_xml: Optional[str] = None):
         (CWD / "assembly"),
         (CWD / "abstract"),
         (CWD / "coff"),
-        "--verbose"
+        "--verbose",
+        "--parallel-threads=4"
     ]
     if junit_xml is not None:
         args.append(f"--junit-xml={junit_xml}")

The traceback I get from attaching to the deadlocked process indicates there are some C++ standard library mutexes in the library and there is a deadlock with the GIL. See https://gist.github.com/ngoldbaum/795789d8449591bc0483ef77c10fd658.

I'm not sure if it makes any sense to run the PyLIEF test suite in a thread pool like this and these deadlocks might not be indicative of real multithreaded usage but it would take some deeper investigation to decide.

[romainthomas]

I think even having wheels on PyPI that re-enable the GIL would be very useful.

I introduced two options to drive the free-threading mode and whether we want a stable ABI build:

LIEF/api/python/backend/config.py

Lines 30 to 31 in 9f6c798

	stable_abi=os.getenv("LIEF_STABLE_ABI", ""),
	free_threaded=os.getenv("LIEF_FREE_THREADED", "")

LIEF/api/python/backend/config.py

Lines 48 to 49 in 9f6c798

	stable_abi: Union[bool, EnvString] = Field(False, alias="stable-abi")
	free_threaded: Union[bool, EnvString] = Field(False, alias="free-threaded")

The idea is also to avoid (a x b x c) configurations for the pre-compiled wheel. Starting from the release 1.0.0,
I'll provide stable ABI wheels for py>=3.12 and 3.14t builds

[reneleonhardt]

There are no future milestones, when can wheels roughly be expected?

[romainthomas]

FYI I made some progress on this issue last weekend and I think it will be completed next weekend.