GpuZelenograd / memtest_vulkan

Vulkan compute tool for testing video memory stability
https://github.com/GpuZelenograd/memtest_vulkan/blob/main/Readme.md
zlib License
262 stars 12 forks source link

Build does not discover and link libvulkan.so.1 #36

Open Atemu opened 3 months ago

Atemu commented 3 months ago

In packaging this for Nixpkgs, I had to resort to patchelf'ing in a NEEDED in order to get memtest_vulkan to discover vulkan-loader.

The build script should discover the vulkan-loader on its own via the likes of pkg-config or cmake or add a mechanism to declare its path somehow.

We put the library into the LDFLAGS, PKG_CONFIG_PATH and CMAKE_PREFIX_PATH by default. We do not have a global library path at runtime (which is how I assume it manages to dlopen libvulkan.so on FHS distros?).

galkinvv commented 3 months ago

Af far as I understand - nixpkgs concept assumes that all paths to the dependecnies are somehow embedded in the binary itself and there is no some per-application ld.so.conf file that can configure paths for dlopen? Please correct me if my undestanding is wrong.

If the preliminary package with patchelf is public - please share the link, it will help my undestanding. Found at https://github.com/NixOS/nixpkgs/pull/296594/files

Regarding the ways to fix it - from the memtest_vulkan arhitecture point of view the best way would be allowing hardcoding path to a vulkan-loader library. By now it is hardcoded in a memtest_vulkan dependency (erupt), but I already planned to rewrite that thing. https://github.com/Friz64/erupt/blob/main/erupt/src/utils/loading.rs#L16

Can the nixpkg build provide some env var like VULKAN_LOADER_DYNAMIC_PATH (or some better name, need to investigate the standards, if nix has some standards for it - please suggest) containing full absoulute path+name of libvulkan.so in the build environment?

If yes - then memtest_vulkan would be able to remember it at build time and use that absolute path for dlopening the loader.

Atemu commented 3 months ago

nixpkgs concept assumes that all paths to the dependecnies are somehow embedded in the binary itself and there is no some per-application ld.so.conf file that can configure paths for dlopen?

That is correct to my knowledge. We put all required libraries' Nix store paths into the rpath of the ELFs and that's how the correct libraries are discovered at runtime.

Here's how that looks on the current (patched) ELF:

$ readelf -d ./result/bin/memtest_vulkan

Dynamic section at offset 0xfa000 contains 32 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libvulkan.so]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/nix/store/ksk3rnb0ljx8gngzk19jlmbjyvac4hw6-glibc-2.38-44/lib:/nix/store/pp0jsd045xvfsz60kpbkfxbs9pbpk8z5-gcc-13.2.0-lib/lib:/nix/store/a00d9xgwkbrqbgw65y1hqq5faq1gkydd-vulkan-loader-1.3.275.0/lib]
 0x000000000000000c (INIT)               0x16000
...

Can the nixpkg build provide some env var like VULKAN_LOADER_DYNAMIC_PATH (or some better name, need to investigate the standards, if nix has some standards for it - please suggest) containing full absoulute path+name of libvulkan.so in the build environment?

Sure, that'd be great.