Open eddyb opened 1 month ago
I don't understand the purpose of such code in production - it looks like a testing hack that got accidentally committed?
Maybe I was right about this, I didn't go back further in time once I saw that the last time I used deqp-vk
the code would've been the same.
But apparently this started with https://github.com/KhronosGroup/VK-GL-CTS/commit/5aa5b0809f055f36fc384644925c384596b2f7cd (Vulkan Video tests).
https://github.com/KhronosGroup/VK-GL-CTS/blob/50e83129b5587b60400ff90abb24bb658630c3eb/framework/delibs/deutil/deDynamicLibrary.c#L40-L49
I don't understand the purpose of such code in production - it looks like a testing hack that got accidentally committed?
The environment variable
LD_LIBRARY_PATH
, just likePATH
, can contain arbitrary entries that should be ignored whenever they are irrelevant to the program itself.Only way I could see this kind of logic making sense is trying both
dlopen(basename((char *)fileName), RTLD_LAZY)
anddlopen(fileName, RTLD_LAZY)
, whenLD_LIBRARY_PATH
is set (because, yes, they can pick different libraries).But which one should you prefer? If the user explicitly passed e.g.:
--deqp-vk-library-path=/my/local/build/of/vulkan-loader/lib/libvulkan.so
Why would that full path be ignored in favor of justlibvulkan.so
?Also, even with
LD_LIBRARY_PATH
unset, there is a hardcoded list of search directories built intolibdl
, sodlopen("libfoo.so")
could still succeed even then. (think/lib64
, but also e.g. automatically appending subpaths likeglibc-hwcaps/x86-64-v3/
etc.)Personally, I had
deqp-vk
work before, and it so happens thatLD_LIBRARY_PATH
isn't set for me normally (e.g. in Konsole), but something or other leads to it being set in VSCode, and I was runningdeqp-vk
from inside VSCode this time.