Linux Python bindings can load foreign `libHalide.so`.

[allemangD]

See #8864 for context and details.

Minimal example: Create an invalid libHalide.so somewhere on the library path, and observe that any Halide Python bindings fail to load:

$ echo '' > ~/.local/lib/libHalide.so
$ pip install halide
$ python -c 'import halide'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import halide
  File ".venv/lib/python3.13/site-packages/halide/__init__.py", line 15, in <module>
    from .halide_ import *  # noqa: E402, F403
    ^^^^^^^^^^^^^^^^^^^^^^
ImportError: ~/.local/lib/libHalide.so: file too short

[alexreinking]

Hmm, I think this is because new toolchains default to setting the RUNPATH rather than RPATH. We can get to RPATH by building with --disable-new-dtags. Versioning the library might be a good idea, too. The bindings don't version because the wheel format doesn't support symlinks (ugh).

[alexreinking]

Actually, we should maybe just force import it via ctypes before loading halide_.

[allemangD]

Actually, we should maybe just force import it via ctypes before loading halide_.

When I was originally writing the workarounds for the problem I discussed in #8864 I used importlib.util.find_spec and ctypes to load the library before import halide.

import ctypes
import importlib.util
import os.path

spec = importlib.util.find_spec('halide')
root = os.path.dirname(spec.origin)
_ = ctypes.cdll.LoadLibrary(os.path.join(root, 'lib64', 'libHalide.so'))

import halide as hl

You can also load the autoscheduler plugins this way, which could possibly be used to simplify hl.load_plugin.

_ = ctypes.cdll.LoadLibrary(join(root, 'lib64', 'libautoschedule_adams2019.so'))

I had done this with halide's spec, but I think you could do the same with halide_'s spec instead.