Skip to content

Conversation

@jbonnell-amd
Copy link
Contributor

@jbonnell-amd jbonnell-amd commented Dec 19, 2025

Motivation

This change will enable the use of third-party builds from TheRock for the dyninst and other dependenices that rocprofiler-systems uses. Previously, rocprofiler-systems was downloading and building these as part of its CMake build process.

If desired, I can split this PR up into smaller chunks based on the third-party dependency that is being added/modified. However, all of these are required to get rocprofiler-systems building in the new way, so it may lead to additional small PRs to get it all merged together in the end and enable the new build method.

Technical Details

  • Added tbb third-party dependency
  • Added binutils third-party dependency
  • Added dyninst third-party dependency
  • Modified boost third-party dependency
    • Added additional packages chrono, date_time, thread, timer which are needed as a dependency for dyninst
  • Modified elfutils third-party dependency
    • Added -fPIC option to CFLAGS and CPPFLAGS to enable PIC (position-independent code) which is required for rocprofiler-systems
  • Updated root level CMakeLists.txt to include THEROCK_BUNDLED_BINUTILS option
  • Updated profiler CMakeLists.txt to remove DROCPROFSYS_BUILD_* CMake arguments, add the new third-party dependencies instead

Test Plan

rocprofiler-systems is able to be built properly with this change, both locally and in pipeline.

Test Result

rocprofiler-systems is able to build successfully without having to download and build its dependencies from source in its build process.

Submission Checklist

rocm-cmake
rocPRIM
therock-googletest
therock-tbb
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason, rocthrust configure kept failing due to this error:

Project contains find_package(TBB) for a package available in the super-project but not declared: Add a BUILD_DEPS or RUNTIME_DEPS appropriately

Not sure where this is coming from but added this for now as a workaround. Would appreciate some insight on what the root cause of this might be

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure that thrust must have an optional dependency on TBB and is probing for it. TheRock doesn't let that happen (for this reason). You can add TBB to thrust to unblock BUILD_DEPS to unblock this PR but we should really have an explicit flag to enable/disable the TBB dep there vs having implicit behavior like this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dread TBB more than Boost 🗡️

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbonnell-amd can you file an issue and link it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done #2837

@jbonnell-amd jbonnell-amd marked this pull request as ready for review December 30, 2025 21:50
@marbre marbre self-requested a review January 5, 2026 09:08
Copy link
Contributor

@geomin12 geomin12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm but I will let Laura or someone more familiar with build to review this

Comment on lines -32 to +38
"-DTHEROCK_BOOST_LIBRARIES=atomic,filesystem,multi_index,system"
"-DTHEROCK_BOOST_LIBRARIES=atomic,chrono,date_time,filesystem,multi_index,system,thread,timer"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Added dyninst third-party dependency
  • Modified boost third-party dependency
    • Added additional packages chrono, date_time, thread, timer which are needed as a dependency for dyninst

We really shouldn't be expanding our dependency on boost, especially not for relatively simple utilities like these. This is especially problematic if the dependency is indirect, as that could make migrating away more difficult.

Should we consider these "grandfathered in" and allow them to be added here, or draw a line and reject them? Either way, the boost dependency must be removed eventually - is the rocprofiler-systems team prioritizing that?

cc @powderluv @stellaraccident

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish we weren't. But we need to get the whole gang in place before giving any of them a haircut.

Comment on lines 82 to 83
COMMAND
make -j 1 V=1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this build step benefit from higher parallelism? Logs at https://therock-ci-artifacts.s3.amazonaws.com/20722897507-linux/logs/gfx94X-dcgpu/therock-binutils_build.log suggest this may be taking 5 minutes? Can we try with multithreading?

See how other dependencies use a PAR_JOBS variable:

include(ProcessorCount)
ProcessorCount(PAR_JOBS)
COMMAND
make -j "${PAR_JOBS}" V=1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I've updated the make command to use the $PAR_JOBS var instead of just using 1. Thanks!

@stellaraccident stellaraccident self-requested a review January 7, 2026 01:32
feature_group = "MEDIA"
disable_platforms = ["windows"]

[artifacts.dyninst]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please set this up as an optional sysdep in the same way as artifacts.sysdeps-amd-mesa.

It is actually a requirement this is set up this way to comply with LGPL licensing (ensures dynamic linkage). And we enforce this for sysdeps (only).

rocm-cmake
rocPRIM
therock-googletest
therock-tbb
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure that thrust must have an optional dependency on TBB and is probing for it. TheRock doesn't let that happen (for this reason). You can add TBB to thrust to unblock BUILD_DEPS to unblock this PR but we should really have an explicit flag to enable/disable the TBB dep there vs having implicit behavior like this.

add_subdirectory(grpc)

# dyninst depends on elfutils, boost, tbb
add_subdirectory(dyninst)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to go into sysdeps/linux as an optional sysdep. Follow the same pattern as was done for amdmesa.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working on moving dyninst into sysdeps/linux on a side branch, I'll merge the changes back over here once it's all done and confirmed working. Thanks for the feedback!

Comment on lines -32 to +38
"-DTHEROCK_BOOST_LIBRARIES=atomic,filesystem,multi_index,system"
"-DTHEROCK_BOOST_LIBRARIES=atomic,chrono,date_time,filesystem,multi_index,system,thread,timer"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish we weren't. But we need to get the whole gang in place before giving any of them a haircut.

]

# binutils
[components.dev."third-party/sysdeps/linux/binutils/build/stage"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make this an optional sysdep in the same pattern as amdmesa, with its own artifact.

"${CMAKE_CURRENT_BINARY_DIR}/s/configure"
--prefix "${CMAKE_INSTALL_PREFIX}"
--enable-install-libiberty
--disable-shared
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment that this is only providing binaries, and even if GPL conditions are satisfied since nothing links to these.

endif()

if(NOT TARGET LibIberty::LibIberty)
add_library(LibIberty::LibIberty STATIC IMPORTED)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libiberty is LGPL licensed. We have to use it as a shared library or not at all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbonnell-amd please ping once these comments are resolved and you want another review.

@marbre
Copy link
Member

marbre commented Jan 13, 2026

We had an issue with a history rewrite which confused the GH UI and the commits it is showing on your PR. Please make sure to update your branch e.g. in the GH UI via

image

Afterwards you need update your local branch via git pull.

Alternative git rebase solution

Alternatively you can manually update your branch locally by following the below instructions:

git checkout <yourbranch>
git fetch origin main
git rebase origin/main
git push --force-with-lease origin <yourbranch>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: TODO

Development

Successfully merging this pull request may close these issues.

8 participants