Torch import failed on .so file despite being present

[kgonia]

Hi, I'm trying to run java + graalpy project. I managed to installed pytorch 2.7.0 using previously built .whl

Hovewer when I'm trying to import it I got:

Import failed: OSError: /graalpy_vfs/venv/lib/python3.12/site-packages/torch/lib/libtorch_global_deps.so: cannot open shared object file: No such file or directory

despite file being present.

Does torch require some additional configuration? I'm able to run polyleven and Pillow, both use the Python C API.

[kgonia]

It happen when vfs is used, if venv is extracted it's working.

Looks like this is problematic part in torch

	lib_name = f"libtorch_global_deps{lib_ext}"
    here = os.path.abspath(__file__)
    global_deps_lib_path = os.path.join(os.path.dirname(here), "lib", lib_name)

    try:
        ctypes.CDLL(global_deps_lib_path, mode=ctypes.RTLD_GLOBAL)

[msimacek]

Hi. The VFS works by redirecting any filesystem IO that graalpy does to the virtualized implementation that is backed by the Jar resources. The limitation is that it can't intercept native IO done from C that doesn't go through python APIs. Which is what's happening here, ctypes is a native module that just calls dlopen on the path and that path doesn't exist in the real filesystem. Since ctypes is part of our codebase, we might be able to patch it to trigger extracting the file before, but I'm not sure if that would help much. Torch is a very large native package that most likely does other things that are not complatible with the FS emulation, so extraction should be the recommended path anyway.

[kgonia]

Do you know if mixed scenario where torch is fully extracted and other libs are exctracted according to defautl behaviour should work?

I tried that and it failed. Only scenario where it worked was full extraction but I noticed loading libs when they are in VFS is faster so I tried this mixed scenario unfortunately without success,

[msimacek]

It's not something we directly support, but you could probably hack it together. Normally, files specified by an extraction filter (default is mostly *.so) get extracted upon first access. And this mechanism tries to also extract all matching files from the same wheel together (because the shared libraries often reference each other with RPATH and that needs real files). You could configure your own extractFilter on the VFS builder, like VirtualFileSystem.newBuilder().extractFilter(p -> p.toString().contains("/site-packages/torch/")).build(). That's just the extraction, the problem with a mixed scenario is that the pythonpath is still the VFS path, so torch would get imported using the VFS paths and then look for the shared library relative to that which will not work. You'd need to trigger the extraction and get the extracted path onto the pythonpath before the VFS paths so that torch gets imported from there. VFS paths with extraction behave like symlinks, resolving them gets you the extracted path. Something like this might work:

import sys
from pathlib import Path
sys.path.insert(0, str(Path('/graalpy_vfs/venv/lib/python3.12/site-packages/torch/__init__.py').resolve().parent.parent))