You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I noticed gpuctypes uses ctypes.util.find_library to dlopen libraries like libcuda.so by direct paths, instead of relying on the dynamic loader to choose the library by name:
Just loading libraries by name (CDLL("libcuda.so")) might often be already sufficient, because the dynamic loader is fairly configurable and the users may adjust its behaviour as is fit for their specific environment: it respects the LD_LIBRARY_PATH environment variable, it checks for the optional /etc/ld.so.conf, and certain entries in the executable's headers.
Additionally, note that the find_library routine doesn't have any clear semantics and it might return the current host's libraries, or it might randomly return a target platform's libraries accidentally found using e.g. gcc. Perhaps you could make find_library an optional "fallback mode"?
Also note that both CDLL("libcuda.so") and find_library("libcuda.so") require extra steps from the user to work, albeit hidden: on the commonly used distributions those would likely succeed and locate libcuda.so through /etc/ld.so.{cache,conf}, but these may not exist or not contain the records about all of the software available on the system. E.g. in Nixpkgs we're going to patch the referenced file(s) with our own paths. Generally, the solution is to explicitly declare the dependency in advance. Cf. e.g. https://discuss.python.org/t/pep-725-specifying-external-dependencies-in-pyproject-toml/31888 for more context
Thanks
The text was updated successfully, but these errors were encountered:
Hi! I noticed
gpuctypes
usesctypes.util.find_library
todlopen
libraries likelibcuda.so
by direct paths, instead of relying on the dynamic loader to choose the library by name:gpuctypes/gpuctypes/cuda.py
Lines 146 to 148 in 77b94ad
Just loading libraries by name (
CDLL("libcuda.so")
) might often be already sufficient, because the dynamic loader is fairly configurable and the users may adjust its behaviour as is fit for their specific environment: it respects theLD_LIBRARY_PATH
environment variable, it checks for the optional/etc/ld.so.conf
, and certain entries in the executable's headers.Additionally, note that the
find_library
routine doesn't have any clear semantics and it might return the current host's libraries, or it might randomly return a target platform's libraries accidentally found using e.g.gcc
. Perhaps you could makefind_library
an optional "fallback mode"?Also note that both
CDLL("libcuda.so")
andfind_library("libcuda.so")
require extra steps from the user to work, albeit hidden: on the commonly used distributions those would likely succeed and locatelibcuda.so
through/etc/ld.so.{cache,conf}
, but these may not exist or not contain the records about all of the software available on the system. E.g. in Nixpkgs we're going to patch the referenced file(s) with our own paths. Generally, the solution is to explicitly declare the dependency in advance. Cf. e.g. https://discuss.python.org/t/pep-725-specifying-external-dependencies-in-pyproject-toml/31888 for more contextThanks
The text was updated successfully, but these errors were encountered: