[Openmp-commits] [openmp] a0fe8bb - [OpenMP][OMPD] Set plugin RUNPATH to identify LLVM Libs (#223691)

via Openmp-commits openmp-commits at lists.llvm.org
Thu Sep 24 01:06:55 PDT 2026


Author: Amit Tiwari
Date: 2026-09-24T13:36:47+05:30
New Revision: a0fe8bbd0143be1a15900faef391dc8b878f856f

URL: https://github.com/llvm/llvm-project/commit/a0fe8bbd0143be1a15900faef391dc8b878f856f
DIFF: https://github.com/llvm/llvm-project/commit/a0fe8bbd0143be1a15900faef391dc8b878f856f.diff

LOG: [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`).

Added: 
    

Modified: 
    openmp/docs/Building.md
    openmp/libompd/gdb-plugin/CMakeLists.txt
    openmp/libompd/gdb-plugin/README.txt

Removed: 
    


################################################################################
diff  --git a/openmp/docs/Building.md b/openmp/docs/Building.md
index 0c5278635e0ae..9db5faa5bf39c 100644
--- a/openmp/docs/Building.md
+++ b/openmp/docs/Building.md
@@ -380,7 +380,10 @@ This option is `OFF` if this feature is not supported for the platform.
 
 **LIBOMP_OMPD_SUPPORT**:BOOL
 : Enable building the libompd library. The GDB plugin loads `libompd.so` with
-LLVM Support `DynamicLibrary` (not POSIX `dlopen`).
+LLVM Support `DynamicLibrary` (not POSIX `dlopen`). On Linux the plugin's
+RUNPATH includes `$ORIGIN` and the relative path to `CMAKE_INSTALL_LIBDIR`
+so GDB can load LLVM Support without extra `LD_LIBRARY_PATH` when LLVM and
+OpenMP share an install prefix.
 
 **LIBOMPD_LD_STD_FLAGS**:STRING
 : Use `-stdlibc++` instead of `-libc++` library for C++.

diff  --git a/openmp/libompd/gdb-plugin/CMakeLists.txt b/openmp/libompd/gdb-plugin/CMakeLists.txt
index aa8db916c5316..495bbd32723e5 100644
--- a/openmp/libompd/gdb-plugin/CMakeLists.txt
+++ b/openmp/libompd/gdb-plugin/CMakeLists.txt
@@ -48,7 +48,31 @@ set_target_properties (ompdModule PROPERTIES PREFIX "")
 set_target_properties (ompdModule PROPERTIES LINKER_LANGUAGE CXX)
 set_target_properties (ompdModule PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/python-module/ompd/")
 
+# ompdModule links LLVMSupport or libLLVM. GDB loads it from
+# ${CMAKE_INSTALL_DATADIR}/gdb/python/ompd/, not from the LLVM library dir. Set
+# RUNPATH so the dynamic linker finds those LLVM libs without LD_LIBRARY_PATH.
+# install(DIRECTORY) copies files as-is and does not rewrite RPATH, so the
+# .so must be installed with install(TARGETS).
+set(_ompd_gdb_plugin_dest "${CMAKE_INSTALL_DATADIR}/gdb/python")
+if(UNIX AND NOT APPLE)
+  if(LLVM_LIBRARY_DIR)
+    set_property(TARGET ompdModule APPEND PROPERTY BUILD_RPATH "${LLVM_LIBRARY_DIR}")
+  endif()
+  set(_ompd_mod_install_dir "${CMAKE_INSTALL_FULL_DATADIR}/gdb/python/ompd")
+  set(_ompd_llvm_lib_install "${CMAKE_INSTALL_FULL_LIBDIR}")
+  file(RELATIVE_PATH _ompd_llvm_lib_rel
+       "${_ompd_mod_install_dir}" "${_ompd_llvm_lib_install}")
+  set_target_properties(ompdModule PROPERTIES
+                        INSTALL_RPATH "\$ORIGIN;\$ORIGIN/${_ompd_llvm_lib_rel}")
+endif()
+
 openmp_register_meta_dep(ompd_gdb_plugin ompdModule)
 
-install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/python-module/ompd DESTINATION share/gdb/python/ COMPONENT openmp PATTERN ompdModule.so PERMISSIONS OWNER_READ WORLD_READ GROUP_READ OWNER_EXECUTE GROUP_EXECUTE WORLD_EXECUTE)
+install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/python-module/ompd
+        DESTINATION ${_ompd_gdb_plugin_dest}
+        COMPONENT openmp
+        PATTERN ompdModule.so EXCLUDE)
+install(TARGETS ompdModule
+        LIBRARY DESTINATION ${_ompd_gdb_plugin_dest}/ompd
+        COMPONENT openmp)
 

diff  --git a/openmp/libompd/gdb-plugin/README.txt b/openmp/libompd/gdb-plugin/README.txt
index 1cc6ce6b2f1f2..125e74f3a9abe 100644
--- a/openmp/libompd/gdb-plugin/README.txt
+++ b/openmp/libompd/gdb-plugin/README.txt
@@ -20,7 +20,7 @@ Instructions to use OpenMP specific debugging support for debugging C/C++ OpenMP
 
         - The gdb command 'help ompd' lists the subcommands available for OpenMP-specific debugging.
         - The command 'ompd init' needs to be run first to load the libompd.so available in the $LD_LIBRARY_PATH environment variable, and to initialize the OMPD library.
-        - The plugin uses LLVM Support to load libompd.so. Put the directory that contains libLLVMSupport.so (or libLLVM.so) on LD_LIBRARY_PATH if GDB cannot load the plugin.
+        - The plugin uses LLVM Support to load libompd.so. After install, ompdModule.so has a RUNPATH back to <prefix>/lib so GDB can find libLLVMSupport.so or libLLVM.so. If LLVM lives in another prefix, put that lib directory on LD_LIBRARY_PATH.
         - The 'ompd init' command starts the program run, and the program stops at a temporary breakpoint at the OpenMP internal location ompd_dll_locations_valid().
         - The user can 'continue' from the temporary breakpoint for further debugging.
         - The user may place breakpoints at the OpenMP internal locations 'ompd_bp_thread_begin' and 'ompd_bp_thread_end' to catch the OpenMP thread begin and thread end events.


        


More information about the Openmp-commits mailing list