RuntimeError: Cannot find the files.
List of candidates:
/home/wookey/bin/libtvm.so
/usr/local/bin/libtvm.so
/usr/bin/libtvm.so
/bin/libtvm.so
/usr/local/games/libtvm.so
/usr/games/libtvm.so
/usr/lib/python3/dist-packages/tvm/libtvm.so
/usr/lib/libtvm.so
/home/wookey/bin/libtvm_runtime.so
/usr/local/bin/libtvm_runtime.so
/usr/bin/libtvm_runtime.so
/bin/libtvm_runtime.so
/usr/local/games/libtvm_runtime.so
/usr/games/libtvm_runtime.so /usr/lib/python3/dist-packages/tvm/libtvm_runtime.so /usr/lib/libtvm_runtime.so
So it tries quite hard to find it, but doesn't know about multiarch
and thus fails to look in the right place:
/usr/lib/<triplet>/Â Â (/usr/lib/x86_64-linux-gnu/ on this box)
I see that /usr/lib/python3/dist-packages/tvm/_ffi/libinfo.py
contains
a function 'get_dll_directories' which looks promising and adds TVM_LIBRARY_PATH to the search list and if I run tvmc like this: Â TVM_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ tvmc
then that path is at the top of the list.
OK, but that mostly reveals a second issue: it's looking for
libtvm.so, but that unversioned link is only provoded in the dev
package
libtvm-dev. The library package has the versioned filenames /usr/lib/x86_64-linux-gnu/libtvm.so.0 /usr/lib/x86_64-linux-gnu/libtvm_runtime.so.0
So I also have to persuade it to look for libtvm.so.0 not
libtvm.so. Where does that info live? OK, a bit more research shows
that that is in /usr/lib/python3/dist-packages/tvm/_ffi/libinfo.py
which is in the source as python/tvm/_ffi_libinfo.py, in
find_lib_path
and that's easy to fix, and probably even the right place to fix it?
The paths is harder though. get_dll_directories in
python/tvm/_ffi_libinfo.py adds $PATH after $LD_LIBRARY_PATH to make
it's search list. Is searching $PATH for libraries ever right?
What it should actually be adding is what's in /etc/ld.so.conf.d/*
That can be listed with
/sbin/ldconfig -v 2>/dev/null | grep -v ^$'\t' | cut -d: -f1
(yuk? is there really no better way?)
How does one do that in python to get that set of path added in the libinfo.py function? https://github.com/apache/tvm/blob/main/python/tvm/_ffi/libinfo.py
Am I barking up the right tree here or is there a better way?
On Fri, 2022-04-01 at 02:32 +0100, Wookey wrote:
So it tries quite hard to find it, but doesn't know about multiarch
and thus fails to look in the right place:
/usr/lib/<triplet>/ (/usr/lib/x86_64-linux-gnu/ on this box)
dlopen should know the multiarch triplet on debian. They have written
their own ffi loader, so I think it is an upstream bug. The upstream
should detect and add multiarch directory to the paths.
OK, but that mostly reveals a second issue: it's looking for
libtvm.so, but that unversioned link is only provoded in the dev
package
libtvm-dev. The library package has the versioned filenames /usr/lib/x86_64-linux-gnu/libtvm.so.0 /usr/lib/x86_64-linux-gnu/libtvm_runtime.so.0
I think it is fine to let it dlopen the libtvm.so, as it says
itself as some sort of "compiler".
Take pytorch as example, python3-torch has some functionalities
for extending itself with C++. As a result, libtorch-dev is
a dependency of python3-torch.
What it should actually be adding is what's in /etc/ld.so.conf.d/*
That can be listed with
/sbin/ldconfig -v 2>/dev/null | grep -v ^$'\t' | cut -d: -f1
(yuk? is there really no better way?)
On 2022-04-01 00:30 -0400, M. Zhou wrote:
They have written
their own ffi loader, so I think it is an upstream bug. The upstream
should detect and add multiarch directory to the paths.
A correct implemntation really should use the full ldconfig set of search paths.
I also don't think it should use the $PATH paths for finding
libraries (but maybe upstream have some reason for doing that)
On Sat, 02 Apr 2022 at 12:55:37 +0100, Wookey wrote:
On 2022-04-01 00:30 -0400, M. Zhou wrote:
They have written
their own ffi loader, so I think it is an upstream bug. The upstream should detect and add multiarch directory to the paths.
A correct implemntation really should use the full ldconfig set of search paths.
I think what they should actually be doing on Linux (at least in distro packages) is taking a step back from all these attempts to reproduce
the system's search path for public shared libraries, and instead doing
this in https://github.com/apache/tvm/blob/main/python/tvm/_ffi/base.py:
ctypes.CDLL('libtvm.so.0')
which will (ask glibc to) do the correct path search, in something like
99% less code.
<CDLL 'libtvm.so.0', handle 1409040 at 0x7f5f0ef48e20>print(lib)
['_name', '_FuncPtr', '_handle', '__module__', '__doc__', '_func_flags_', '_func_restype_', '__init__', '__repr__', '__getattr__', '__getitem__', '__dict__', '__weakref__', '__hash__', '__str__', '__getattribute__', '__setattr__', '__delattr__', '__lt__',print(lib.__dir__())
Traceback (most recent call last):print(lib.wibble)
Maybe all this complexity is needed on Windows or in a "relocatable"
package, but for a distro package it's completely unnecessary and
sometimes harmful.
I also don't think it should use the $PATH paths for finding
libraries (but maybe upstream have some reason for doing that)
I suspect the reason is: on Windows, PATH is the equivalent of Linux PATH, but it also has a dual role as the equivalent of Linux LD_LIBRARY_PATH.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 384 |
Nodes: | 16 (2 / 14) |
Uptime: | 62:52:25 |
Calls: | 8,174 |
Calls today: | 6 |
Files: | 13,113 |
Messages: | 5,864,574 |