Hello, On 2024-11-27 23:10, Cordell Bloor wrote:
The pytorch-rocm package uses find_package(hiprtc) and links to hiprtc::hiprtc. This fails with the error:CMake Error at /usr/lib/x86_64-linux-gnu/cmake/hiprtc/hiprtc-targets.cmake:79 (message): The imported target "hiprtc::hiprtc" references the file "/usr/lib/x86_64-linux-gnu/libhiprtc.so.5.7.31921" The Debian build for rocm-hipamd discards this library. IIRC, this was because the same symbols were provided by some other binary (or something like that). If that is the case, then the Debian definition of hiprtc::hiprtc should probably point to that other library that provides the symbols. Or a symlink should be created. Or some other solution should be found. I'm not sure what the proper solution should look like, but whatever is decided upon, the hiprtc::hiprtc target should have a valid definition.
I asked the HIP Runtime team about this and they told me that libamdhip64.so provides the same symbols as libhiprtc.so as a matter of backwards-compatibility. This functionality was all in libamdhip64.so originally, but was moved into libhiprtc.so later. In ROCm 7.0, it is likely that libamdhip64.so will bump its SOVERSION and drop the symbols found in libhiprtc.so.
I'm not certain of the best way to address this. I believe this bug affects Bookworm and Trixie (as well as Ubuntu Noble). One possibility would be to adjust the definition of `hiprtc::hiprtc` on Debian to point to libamdhip64.so. For Trixie, I imagine that the right solution is to begin shipping a libhiprtc in its own package, but I'm less certain about how to best address this bug in Bookworm / Noble.
Sincerely, Cory Bloor
