[pathfinder] RTLD_DI_LINKMAP-based new implementation of abs_path_for_dynamic_library()

[rwgk]

Closes #833

Also a step towards resolving #776 — please see comments there.

This PR eliminates supported_nvidia_libs.EXPECTED_LIB_SYMBOLS entirely, which is a major simplification in its own right.

Piggy-backed: Minor fix (commit d13ad8e) and cleanup (commit e716f1c).

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[rwgk]

/ok to test

[copy-pr-bot]

Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[rwgk]

/ok to test

[leofang]

I am a bit nervous about us using either dladdr or dlinfo since none of them is POSIX-compliant. Since dladdr has been used, switching to dlinfo does not make it more "non-compliant", so it's still a step forward. We just have to see if it runs everywhere...

[rwgk]

since none of them is POSIX-compliant

Do you think the ChatGPT conclusion below is reasonable?

My ChatGPT prompt:

---

This makes me want to ask:

Does CUDA run on any systems that are not Linux or Windows?

(Windows dynamic loading is handled separately. I.e. basically I'm only asking: does CUDA run on any Unix system that is not Linux?)

Do you know?

---

ChatGPT said:

Thought for 19s

Short answer: No. Today CUDA is officially supported on Linux (various distros/arches, including aarch64/Jetson) and Windows (including WSL2 Linux environments on Windows). There’s no current macOS runtime support, and no official support for other Unix-like OSes (e.g., *BSD).

So if your scope is “Linux only,” it’s reasonable to lean on glibc-specific behavior (e.g., dlinfo)—CUDA isn’t targeting musl/Alpine or non-Linux Unix platforms.

---

[rwgk]

/ok to test

[kkraus14]

LGTM

[rwgk]

/ok to test

[rwgk]

/ok to test

[leofang]

Breaking out from this thread since it's getting a bit long and I want to leave another comment there to keep it focused.

Q: Can't we just use RTLD_DI_ORIGIN and get the path back

Turns out we can.

RTLD_DI_ORIGIN = 6
mylib = ctypes.CDLL(...)

path_buf = ctypes.create_string_buffer(4096)
rc = LIBDL.dlinfo(ctypes.c_void_p(mylib._handle), RTLD_DI_ORIGIN, path_buf)
if rc != 0:
    err = _dl_last_error()
    raise OSError(f"dlinfo failed for {libname=!r} (rc={rc})" + (f": {err}" if err else ""))

print(f"origin = {path_buf.value.decode()}")

But for all practical use cases that the pathfinder covers, origin is exactly the same as os.path.dirname(path_from_link_map), where path_from_link_map is the DSO path retrieved via querying RTLD_DI_LINKMAP as done in the current PR.

The only edge case where RTLD_DI_LINKMAP would not work is if mylib loads a DSO via a relative path. In this case, only RTLD_DI_ORIGIN would return the correct abs path to the directory containing the DSO. But as mentioned this is a case that the pathfinder does not cover by design.

In fact, it might be a good idea to expand the new validate_abs_path test to use this query? It's not a blocker, ofc.

[leofang]

Thanks, Ralf, LGTM too!

[rwgk]

Thanks @leofang , I hadn't seen RTLD_DI_ORIGIN before.

To be sure that we can rely on it being available, I looked up when it was added in the glibc repo:

commit 45e4762c2c7d04cd51213735c2b440c94cdcf28a
Date:   Sat Mar 15 23:16:22 2003 +0000

It's defined in dlfcn/dlfcn.h with this comment (which hasn't changed at all for 22+ years!):

    /* Treat ARG as `char *', and store there the directory name used to
       expand $ORIGIN in this shared object's dependency file names.  */
    RTLD_DI_ORIGIN = 6,

That makes me think it's only a "directory name", and we'd still have to get the filename from somewhere else.

The only edge case where RTLD_DI_LINKMAP would not work is if mylib loads a DSO via a relative path. In this case, only RTLD_DI_ORIGIN would return the correct abs path to the directory containing the DSO. But as mentioned this is a case that the pathfinder does not cover by design.

I'll play with this later tonight, to verify that a relative path is in fact not expanded to a full absolute path. If that's true, I'll add a comment in load_dl_linux.py before merging this PR.

[rwgk]

That makes me think it's only a "directory name",

Confirmed.

a relative path is in fact not expanded to a full absolute path.

Also confirmed.

Putting 1 + 1 together in commit 66c5869:

l_origin + basename(l_name) → abs_path

@leofang as you said, currently pathfinder does not really need this, but it's easy enough to make it complete.

[rwgk]

/ok to test

[rwgk]

For completeness, here is how I confirmed the dlinfo behavior:

• https://github.com/rwgk/rwgk_config/blob/9ae0510debd5ce3b66c547328c8a99ec6d308149/bin/try_dlopen.py

$ cd /lib
$ try_dlopen.py x86_64-linux-gnu/libcufftMp.so.11
dlopen succeeded: 'x86_64-linux-gnu/libcufftMp.so.11'
  l_name: 'x86_64-linux-gnu/libcufftMp.so.11'
  l_origin: '/usr/lib/x86_64-linux-gnu'
  abs_path: '/usr/lib/x86_64-linux-gnu/libcufftMp.so.11'

$ cd
$ try_dlopen.py libnvJitLink.so.13
dlopen succeeded: 'libnvJitLink.so.13'
  l_name: '/usr/local/cuda/lib64/libnvJitLink.so.13'
  l_origin: '/usr/local/cuda/lib64'
  abs_path: '/usr/local/cuda/lib64/libnvJitLink.so.13'

[leofang]

That makes me think it's only a "directory name", and we'd still have to get the filename from somewhere else.

Yes. As mentioned earlier:

origin is exactly the same as os.path.dirname(path_from_link_map), where path_from_link_map is the DSO path retrieved via querying RTLD_DI_LINKMAP as done in the current PR.

dirname() is the (abs) directory path. And we already have the filename.

[github-actions]

Doc Preview CI
Preview removed because the pull request was closed or merged.