Update build_python_packages.py to package rocprofiler-compute and rocprofiler-systems into profiler wheel: Phase 3

[erman-gurses]

Progress on #3573

Motivation

This PR introduces a dedicated rocm-profiler wheel for rocprof-sys and rocprof-compute by packaging directly from profiler artifacts instead of relying on base.

The goal is to:

• Package rocprofiler-compute and rocprofiler-systems into a dedicated profiler wheel
• Ensure CLI tools (rocprof-compute, rocprof-sys-*) are available and functional from the installed wheel
• Align packaging with TheRock’s artifact-driven model
• Resolve runtime dependency issues (sysdeps and libomp) so profiler tools execute correctly

---

Technical Details

Artifact Selection

• Switched profiler artifact selection to:
  • rocprofiler-compute (lib, run)
  • rocprofiler-systems (lib, run)
• Extended selection to include:
  • sysdeps (lib) for runtime dependency closure

Runtime Payload Updates

• Added required rocm_sysdeps runtime libraries:
  • librocm_sysdeps_dw.so*
  • librocm_sysdeps_elf.so*
  • librocm_sysdeps_z.so*
  • librocm_sysdeps_zstd.so*
  • librocm_sysdeps_liblzma.so*
  • librocm_sysdeps_bz2.so*

RPATH Fixes

• Added additional RPATH dependency:
  • core/lib
  • core/lib/llvm/lib
• This enables resolution of libomp.so from rocm-sdk-core

CLI Runtime Fix

• Updated _cli.py to extend LD_LIBRARY_PATH at runtime:
  • Points to _rocm_sdk_core/lib/rocm_sysdeps/lib
• Ensures packaged sysdeps are visible to profiler binaries

Other Packaging Updates

• Recreated missing symlink:
  • bin/rocprof-compute -> ../libexec/rocprofiler-compute/rocprof-compute
• Updated packaging templates to include _rocm_profiler platform files
• Ensured artifact-driven packaging instead of relying on base

---

Test Plan

Artifact Preparation

• Synced CI artifacts:

  s3://therock-ci-artifacts/24104028483-linux/
  

• Extracted:
  • base_{lib,run}_generic
  • rocprofiler-compute_{lib,run}_generic
  • rocprofiler-systems_{lib,run}_generic
  • sysdeps_lib_generic
  • amd-llvm_lib_generic

Build

python build_tools/build_python_packages.py \
  --artifact-dir ~/therock-multiarch-root \
  --dest-dir /tmp/therock-profiler-test \
  --build-packages

Install

pip install --force-reinstall rocm_sdk_core-*.whl
pip install --force-reinstall rocm_profiler-*.whl

Validation

rocprof-compute --help
rocprof-sys-python --help
rocprof-sys-run --help
rocprof-sys-avail --help
rocprof-sys-causal --help
rocprof-sys-instrument --help
rocprof-sys-sample --help

Dependency Checks

ldd .../rocprof-sys-instrument | grep libomp
ldd .../rocprof-sys-run | grep "not found"

---

Test Result

Verified the following profiler entrypoints execute successfully from the installed wheel:

- rocprof-compute --help
- rocprof-sys-python --help
- rocprof-sys-run --help
- rocprof-sys-avail --help
- rocprof-sys-causal --help
- rocprof-sys-instrument --help
- rocprof-sys-sample --help

All commands print usage without missing shared library errors.

• rocprof-compute --help executes successfully

• All rocprof-sys-* entrypoints execute and print usage:

  • run, avail, causal, instrument, sample

• libomp.so is correctly resolved from rocm-sdk-core:

  libomp.so => _rocm_sdk_core/lib/llvm/lib/libomp.so
  

• All required sysdeps libraries are now packaged and resolved:

  • librocm_sysdeps_dw.so.1
  • librocm_sysdeps_elf.so.1
  • librocm_sysdeps_z.so.1
  • librocm_sysdeps_zstd.so.1
  • librocm_sysdeps_liblzma.so.5
  • librocm_sysdeps_bz2.so

• No remaining missing dependency errors from ldd

• Remaining runtime output is limited to host /opt/rocm warnings (e.g. libamd_smi.so.26), not missing packaging content

---

Summary

• rocm-profiler is now correctly built from profiler artifacts
• Runtime dependency closure (sysdeps + LLVM/OpenMP) is resolved
• Profiler tools execute successfully from installed wheels
• Remaining issues are limited to external host ROCm linkage, not packaging

[jbonnell-amd]

Just to confirm, the librocm_sysdeps .so files are present in the python package but are just not linked properly? We had some issues with this before where you had to manually set LD_LIBRARY_PATH to point to the rocm_sysdeps, wanted to confirm that we can still do the same workaround to get around this for now

[erman-gurses]

Just to confirm, the librocm_sysdeps .so files are present in the python package but are just not linked properly? We had some issues with this before where you had to manually set LD_LIBRARY_PATH to point to the rocm_sysdeps, wanted to confirm that we can still do the same workaround to get around this for now

I just double checked - so yes - at this point the librocm_sysdeps shared libraries are present in the packaged Python wheels. The issue was runtime resolution, not that the files were absent.

Addressed that by (1) including the required rocm_sysdeps runtime libraries from the sysdeps artifacts in the rocm-profiler packaging, (2) adding an rpath dependency on rocm-sdk-core/lib/llvm/lib to resolve libomp.so, and (3) extending LD_LIBRARY_PATH at runtime in the profiler CLI to point to the packaged sysdeps location. With these changes, the rocprof-sys-* tools are now launching successfully from the wheel.

As a temporary workaround, manually setting LD_LIBRARY_PATH to point at the packaged rocm_sysdeps location would still work if needed. In this case that path is under the installed wheel, e.g. _rocm_sdk_core/lib/rocm_sysdeps/lib.

@jbonnell-amd, FYI, updated the code.

[jbonnell-amd]

Looks good! @dgaliffiAMD any comments regarding the rpath/libs for rocprofiler-systems?

[dgaliffiAMD]

I pulled the latest artifacts from https://therock-ci-artifacts.s3.amazonaws.com/24581668095-linux/python/gfx94X-dcgpu/index.html and ran some basic tests, like rocprof-sys-sample -- ls -al.

• I noticed that rocprof-sys-attach is missing. This was new to 7.12, so it was probably missing from your initial phase.
• The missing sqlite3 library was fixed with your latest changes.
• Related to your previous change, you are patching the RPATHS to add $ORIGIN/../../_rocm_sdk_core/lib:$ORIGIN/../../_rocm_sdk_core/lib/llvm/lib. Additionally, could you add $ORIGIN/../../_rocm_sdk_core/lib/rocm_sysdeps/lib? This would reduce the need to have duplicate copies of those libraries.
• I noticed the symbolic links to the libraries are not created with the PIP installs. For example, librocprof-sys.so.1 is present, but not librocprof-sys.so or librocprof-sys.so.1.6.0. Is that intentional.
  • Found an issue with our dlopen calls. For example, librocproc-sys-dl.so fails because only librocproc-sys-dl.so.1. We should fix this before merging this change. Either by manually creating those symbolic links or by changing the logic in our tool. We could do both, but the latter will take longer because we will be stuck waiting for the submodule bump.

[erman-gurses]

@dgaliffiAMD, thanks for the feedback - I answered your questions and update the code. Please see below:

I pulled the latest artifacts from https://therock-ci-artifacts.s3.amazonaws.com/24581668095-linux/python/gfx94X-dcgpu/index.html and ran some basic tests, like rocprof-sys-sample -- ls -al.

I noticed that rocprof-sys-attach is missing. This was new to 7.12, so it was probably missing from your initial phase.

rocprof-sys-attach is present in the rocprofiler-systems artifact and was missed in the initial packaging.
I will include rocprof-sys-attach in the profiler wheel entry-point in a follow-up PR.

The missing sqlite3 library was fixed with your latest changes.

Thanks for confirming — this is now resolved with the latest changes. The required sysdeps (including sqlite3) are pulled from _rocm_sdk_core and resolve correctly at runtime.

Related to your previous change, you are patching the RPATHS to add $ORIGIN/../../_rocm_sdk_core/lib:$ORIGIN/../../_rocm_sdk_core/lib/llvm/lib. Additionally, could you add $ORIGIN/../../_rocm_sdk_core/lib/rocm_sysdeps/lib? This would reduce the need to have duplicate copies of those libraries.

I added _rocm_sdk_core/lib/rocm_sysdeps/lib to the profiler RPATHs and removed the duplicate sysdeps payload from rocm-profiler. With this, profiler binaries resolve librocm_sysdeps_* directly from _rocm_sdk_core, avoiding duplication.
This was verified via ldd, which now shows sysdeps resolving from _rocm_sdk_core/lib/rocm_sysdeps/lib.

• I noticed the symbolic links to the libraries are not created with the PIP installs. For example, librocprof-sys.so.1 is present, but not librocprof-sys.so or librocprof-sys.so.1.6.0. Is that intentional.
  Yes — I addressed this in the latest update.
  • Found an issue with our dlopen calls. For example, librocproc-sys-dl.so fails because only librocproc-sys-dl.so.1. We should fix this before merging this change. Either by manually creating those symbolic links or by changing the logic in our tool. We could do both, but the latter will take longer because we will be stuck waiting for the submodule bump.

This was not intentional — thanks for pointing it out.
Previously, only versioned libraries (e.g. librocprof-sys-dl.so.1) were packaged, while the runtime uses dlopen() with unversioned names (e.g. librocprof-sys-dl.so), which caused the failures.
I fixed this by recreating the expected unversioned symlinks during packaging (e.g. librocprof-sys-dl.so → librocprof-sys-dl.so.1, and similarly for other rocprof-sys libraries)
I verified that:

• the symlinks are present after pip install
• dlopen() succeeds
• rocprof-sys-* tools run correctly from the installed wheel

Given the submodule dependency, I implemented this fix in packaging to unblock the PR. We can consider updating the dlopen logic upstream in a follow-up to make it more robust to versioned names.

[dgaliffiAMD]

Sorry, still waiting for the workflows to complete, so I can look at the packages. It seems like you have everything covered though. Do you have any concerns with the maintainability of that new map that you added?

[erman-gurses]

Sorry, still waiting for the workflows to complete, so I can look at the packages. It seems like you have everything covered though. Do you have any concerns with the maintainability of that new map that you added?

No worries, thanks again for your feedback, yes, I do have a maintainability concern with the explicit map, but I think it is acceptable for this step. I can come up with better solution soon in the follow up PRs

I have more phases to finalize this packaging, currently I am in Phase 3. Please see: #3573. So, I can take a look better solution before I jump to the Phase 4 and 5.