Fix xilinx_xrt() root discovery on Debian multiarch installs (#9955) - #9958
Merged
Conversation
…9955) xilinx_xrt() derived the XRT root by taking two parent_path() levels up from the libxrt_coreutil.so path reported by dladdr(). This assumes coreutil lives directly in <root>/lib, which only holds when CMAKE_INSTALL_LIBDIR is a single path component (lib, lib64). On a Debian multiarch install CMAKE_INSTALL_LIBDIR is lib/x86_64-linux-gnu, so coreutil is one level deeper and the two-level strip returns <root>/lib instead of <root>. shim_path() then re-appends XRT_LIB_DIR, producing a doubled path such as '/opt/amdgpu/lib/lib/x86_64-linux-gnu/libxrt_core.so.2' and the load fails with "No such library". Strip exactly as many trailing components as XRT_LIB_DIR contains instead of a hardcoded two levels, so the root is recovered correctly for lib, lib64, and lib/x86_64-linux-gnu layouts alike. Single-component layouts (standard, lib64, single-arch Yocto) are unaffected. Also default XRT_LIB_DIR to "lib" so the header stays self-contained; the loop additionally tolerates an empty value. Regression from 11169ba (SWSPLAT-24084) which switched XRT root discovery from XILINX_XRT to dladdr(). Signed-off-by: Wendy Liang <wendy.liang@amd.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> (cherry picked from commit 5403f66)
maxzhen
approved these changes
Aug 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
xilinx_xrt() derived the XRT root by taking two parent_path() levels up from the libxrt_coreutil.so path reported by dladdr(). This assumes coreutil lives directly in /lib, which only holds when CMAKE_INSTALL_LIBDIR is a single path component (lib, lib64). On a Debian multiarch install CMAKE_INSTALL_LIBDIR is lib/x86_64-linux-gnu, so coreutil is one level deeper and the two-level strip returns /lib instead of . shim_path() then re-appends XRT_LIB_DIR, producing a doubled path such as
'/opt/amdgpu/lib/lib/x86_64-linux-gnu/libxrt_core.so.2' and the load fails with "No such library".
Strip exactly as many trailing components as XRT_LIB_DIR contains instead of a hardcoded two levels, so the root is recovered correctly for lib, lib64, and lib/x86_64-linux-gnu layouts alike. Single-component layouts (standard, lib64, single-arch Yocto) are unaffected. Also default XRT_LIB_DIR to "lib" so the header stays self-contained; the loop additionally tolerates an empty value.
Regression from 11169ba (SWSPLAT-24084) which switched XRT root discovery from XILINX_XRT to dladdr().
(cherry picked from commit 5403f66)