[Feature]: Add dlopen locator for better NIX integration

[elezar]

The NIX package for the NVIDIA Container Toolkit adds a library locator that uses dlopen to attempt to locate libraries: https://github.com/NixOS/nixpkgs/blob/1c415018b24020442ee94e6b84a8a4a24078a61e/pkgs/by-name/nv/nvidia-container-toolkit/0001-Add-dlopen-discoverer.patch#L50

In order to provide better support for NIX, we should consider adding such a locator -- at least for certain types of libraries.

This was already done in #1646 but removed again in #1676 due to instability.

One option would be to allow the types of locators used for libraries to be configurable. See

• f62813c
• c1af7f5

[cdesiniotis]

In order to provide better support for NIX, we should consider adding such a locator -- at least for certain types of libraries.

Would you be able to explain why this is needed for NIX? Admittedly I am not very familiar with NIX.

[zeusec]

I ran into this while bumping the package to 1.19.1 in nixpkgs (NixOS/nixpkgs#534577), so here's what's happening on the Nix side.

NixOS doesn't have a normal /usr/lib or a populated ld.so.cache. Everything lives under /nix/store/..., and the NVIDIA driver libs get surfaced to apps through a single symlink dir, /run/opengl-driver/lib, which is baked into the binary's RUNPATH at build time. That's how nvidia-ctk itself is linked.

So the usual FHS-path and ldcache lookups come up empty for the driver libs, even though they load fine at runtime via the RUNPATH. dlopen bridges that, it hands the lookup to the dynamic linker, which resolves them, and dlinfo(RTLD_DI_ORIGIN) gives back the real path to mount.

The configurable-locator direction you've already started in f62813c / c1af7f5 looks like it'd cover this. Glad to help test the Nix side if it's useful...