[all-commits] [llvm/llvm-project] a0fe8b: [OpenMP][OMPD] Set plugin RUNPATH to identify LLVM...

[Amit Tiwari via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a0fe8bbd0143be1a15900faef391dc8b878f856f
      https://github.com/llvm/llvm-project/commit/a0fe8bbd0143be1a15900faef391dc8b878f856f
  Author: Amit Tiwari <Amit.Tiwari at amd.com>
  Date:   2026-09-24 (Thu, 24 Sep 2026)

  Changed paths:
    M openmp/docs/Building.md
    M openmp/libompd/gdb-plugin/CMakeLists.txt
    M openmp/libompd/gdb-plugin/README.txt

  Log Message:
  -----------
  [OpenMP][OMPD] Set plugin RUNPATH to identify LLVM Libs (#223691)

`ompdModule` links LLVMSupport, but GDB loads it from
`share/gdb/python/ompd/ompdModule.so` while LLVM libs lives in
`lib/LLVMSupport.so` or `lib/LLVM.so`. The dynamic linker (one that
opens .so files) loosk at:
1) paths inside .so (aka RUNPATH)
2) `LD_LIBRARY_PATH`
3) or system defaults paths

After [previous
patch](https://github.com/llvm/llvm-project/pull/222455), a normal
install can fail with "cannot open shared object file" unless the user
sets `LD_LIBRARY_PATH` by hand which is easy to forget after `ninja
install`.

Fix: The approach is to make CMake write RUNPATH on `ompdModule.so`, so
the plugin follows its own directions and hence the linker (same
approach LLDB uses for its Python module). This completes the LLVM link
added in the previous patch. It does not change how `libompd.so` is
located (still `ompd_dll_locations`/`LD_LIBRARY_PATH`).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications