Debian Patches

Status for rocm-hipamd/7.2.4-1~exp1

Patch Description Author Forwarded Bugs Origin Last update
0001-dotdots.patch adjust dotdots directories around _IMPORT_PREFIX

Note the patch has been partially applied around ROCm 5.2, so there could be a
consistency issue if the below code were to not be necessary anymore.		 Cordell Bloor <cgmb-deb@slerp.xyz> yes 2024-02-27
0002-replace-x86_64-with-variables.patch replace x86_64 with variables
The changes to hipcc.pl and hip_embed_pch won't allow cross-compiling,
but they will enable the build to proceed on other architectures.		 Cordell Bloor <cgmb@slerp.xyz> yes upstream 2023-02-14
0004-make-hipcc-and-hipconfig-optional.patch make hipcc and hipconfig optional
The set_and_check macro is essentially just

set(var "${file}")
if(NOT EXISTS "${file}")
message(FATAL_ERROR ...)
endif()

so it can be made optional by first doing the exists check and only
doing the set if the file does exist.		 Cordell Bloor <cgmb@slerp.xyz> no debian 2023-05-22
0009-default-to-hip-platform-amd.patch default to hip platform amd
The hipconfig executable is part of the hipcc package, so it is not
always available when building libraries that depend on HIP.

The -DHIP_PLATFORM=amd option could be specified explicitly during
configuration, so this default value is not strictly necessary.
However, HIP 5.2 defaulted to the amd platform and it would be annoying
to cause any libraries to FTBFS just due to the update to HIP 5.7.

We should reevaluate whether we want to keep this patch when updating to
ROCm 6. That said, it seems like a useful default to me.		 Cordell Bloor <cgmb@slerp.xyz> no 2026-06-11
0010-optional-device-libs-find-package.patch optional device libs for hip find package
When users do find_package(hip REQUIRED), the REQUIRED argument gets
forwarded to find_dependency. However, the device libraries are not
required for many libraries that are using HIP (e.g., C or C++
applications that only use the HIP host interfaces).		 Cordell Bloor <cgmb@slerp.xyz> no 2024-03-22
0011-deduplicate-cmake-messages.patch deduplicate hip cmake config messages
It's questionable whether this even needs to be printed once,
let alone multiple times.		 Cordell Bloor <cgmb@slerp.xyz> no 2024-03-22
0012-do-not-install-hipcc.patch hipcc is now shipped by the rocm-llvm src package,so we should not install these files here. Xuanteng Huang <xuanteng.huang@outlook.com> not-needed 2026-06-11
0013-fix-FindHIP-search-for-HIP_CLANG_PATH.patch fix FindHIP search for HIP_CLANG_PATH Cordell Bloor <cgmb@slerp.xyz> no 2025-04-17
0014-fix-roc-obj-help.patch fix roc-obj help
Defining the appropriate Getopt::Std variables and functions prevents
the --help command from printing this sort of weird output:

/usr/bin/roc-obj-ls version [unknown] calling Getopt::Std::getopts (version 1.14 [paranoid]),
running under Perl version 5.40.1.
<...>
[Now continuing due to backward compatibility and excessive paranoia.
See 'perldoc Getopt::Std' about $Getopt::Std::STANDARD_HELP_VERSION.]		 Cordell Bloor <cgmb@slerp.xyz> no debian 2025-04-18
0017-optional-hipconfig-in-build-depends.patch optional hipconfig in build-depends
This patch is needed to break the cycle between src:rocm-llvm and
src:rocm-hipamd.		 Cordell Bloor <cgmb@debian.org> no 2025-07-20
0018-skip-opencl-tools.patch skip opencl tools
Skip build of OpenCL tools. These are not building successfully
and aren't packaged anyway.		 Cordell Bloor <cgmb@debian.org> not-needed 2025-09-04
0019-fix-amdocl-library-version.patch fix amdocl library version
This patch is necessary to fix the version symlinks for libamdocl64.so		 Cordell Bloor <cgmb@debian.org> no 2025-09-05
0020-spelling.patch spelling
note 20251113(tflink): disabling for now. most of these have been fixed. will
re-check with lintian		 Cordell Bloor <cgmb@debian.org> no 2026-06-11
0017-fix-memory-barriers-for-arm64-and-ppc64.patch fix memory barriers for arm64 and ppc64 Cordell Bloor <cgmb@debian.org> no 2026-06-11
0021-dont-change-default-c-cxx-flags.patch Restore default C and C++ flags Remove warning treating all warnings as errors temporarily
when compiling with gcc.
Note: This patch was taken from the rocm-experimental ppa.
<https://launchpad.net/~tflink/+archive/ubuntu/rocm-experimental/+packages>		 Tim Flink <tflink@tirfa.com> no 2025-09-29
0022-remove-hardcoded-optrocm-hipamd-cmake.patch =================================================================== no
0023-compat-hipLibraryLoad-single-pointer.patch add C++ compatibility overloads for hipLibraryLoad* signature fix In ROCm 7.1.0 the jitOptions and libraryOptions parameters of
hipLibraryLoadData() and hipLibraryLoadFromFile() were incorrectly declared
as double pointers (hipJitOption** / hipLibraryOption**), diverging from the
CUDA cuLibraryLoadData API and from every other HIP function that accepts
hipJitOption (e.g. hipModuleLoadDataEx, hipLinkCreate). ROCm 7.1.1 fixed
the signatures to use single pointers, matching the CUDA API.
.
This patch adds inline C++ overloads (inside an extern "C++" block to escape
the surrounding extern "C" linkage of hip_runtime_api.h) that accept the old
double-pointer signatures and forward them to the corrected single-pointer
versions, restoring source-level backwards compatibility for code compiled
against the 7.1.0 headers.
.
The forwarding dereferences the double pointer (*jitOptions, *libraryOptions)
as that is the semantically correct conversion: a 7.1.0 caller would have
passed &opts_array (hipJitOption**), and the 7.1.1 API expects opts_array
(hipJitOption*). In practice the pointer value is never read by the
implementation — JIT options are unsupported on AMD devices and passing
numJitOptions > 0 returns hipErrorInvalidValue immediately — so the
dereference is a no-op at runtime, but it is the correct semantic transform.
.
C clients are not affected: all reverse dependencies of libamdhip64-dev in
the archive are C++ ROCm compute libraries. hipLibraryLoad* is a HIP
dynamic library loading API used exclusively from C++ HIP application code.		 Igor Luppi <igor.luppi@canonical.com> not-needed 2026-06-11
0024-restrict-hiprtc-cmake-search-to-clang-22.patch restrict hiprtc cmake search to clang-22
Restrict the LLVM find_package search to clang-22 and ensure that the
search for clang prefers the same package found for LLVM. This is not
a problem for the upstream project, as it only ships one version of
clang.

[ Bruno Bernardo de Moura ]
Reapplied patch on new file structure for clang 22 based on previously
dropped 0007-restrict-hiprtc-cmake-search-to-clang-21.patch.		 Cordell Bloor <cgmb@slerp.xyz> not-needed 2026-05-25
0025-roc-obj-use-llvm-22.patch roc-obj use llvm-22
Use the same LLVM version as the rest of the ROCm stack, so we don't
need to install multiple versions of LLVM just for roc-obj.

[ Bruno Bernardo de Moura ]
Reapplied patch on new file structure for clang 22 based on previously
dropped 0016-roc-obj-use-llvm-21.patch.		 Cordell Bloor <cgmb@slerp.xyz> not-needed 2026-05-25
0026-hip-embed-pch-stable-cwd.patch hip_embed_pch: make embedded PCH bit-for-bit reproducible
Two unrelated sources of non-determinism leak into the embedded PCH
that ships as ``.data`` inside libamdhip64.so, breaking
reproducible-builds (debrebuild reports ``size differs`` for
``libamdhip64-7_*.deb``):

1. ``clang -cc1 -emit-pch -x hip-cpp-output -`` records the source
filename as ``<stdin>`` prefixed with the *current working
directory*, and that string ends up in the embedded PCH (twice --
once per wave size). When the build path varies, the embedded
string varies with it, and lintian also flags
``file-references-package-build-path``.

2. The script keeps its scratch state under ``/tmp/hip_pch.$$`` where
``$$`` is the bash PID. The first ``clang -E`` invocation writes
``# 1 "/tmp/hip_pch.<pid>/hip_pch.h"`` line markers into the .cui
file. Those markers are then re-parsed by the second
``-emit-pch`` invocation (which reads the .cui as
``hip-cpp-output``) and the PID leaks into the serialized PCH
bitcode (most likely via the SourceManager content hash that clang
records for the input buffer). Different PIDs across builds
therefore produce different libamdhip64.so bytes -- the
debrebuild ``.data`` diff shows exactly two single-byte deltas per
PCH, repeated for wave32 and wave64, matching this hypothesis.

Fix both:

* Run the two ``-emit-pch`` invocations from ``/`` so the recorded
``<stdin>`` path is a constant ``/<stdin>`` independent of the
build directory.
* Pin the scratch directory to a deterministic name and clean it up
before use, so the line markers embedded in
``pch_wave{32,64}.cui`` no longer carry a PID.

``hip_embed_pch.sh`` is only invoked once per build by CMake, so a
fixed scratch path cannot race with itself.		 Talha Can Havadar <havadartalha@gmail.com> yes upstream 2026-05-31
0027-fix-hip-clang-root-for-debian-layout.patch fix HIP_CLANG_ROOT for the Debian/Ubuntu layout
On the upstream /opt/rocm layout the LLVM toolchain lives under
${ROCM_PATH}/llvm, so hip-config-amd.cmake hardcodes
HIP_CLANG_ROOT="${ROCM_PATH}/llvm" and looks up amdgpu-arch at
${HIP_CLANG_ROOT}/bin/amdgpu-arch. On Debian/Ubuntu ROCM_PATH resolves
to /usr, there is no /usr/llvm, and amdgpu-arch is not at /usr/bin
result GPU autodetection silently fails, GPU_TARGETS is left empty and
device code is built for the default gfx906, which segfaults at runtime
on other GPUs.

Derive HIP_CLANG_ROOT from the resolved (symlink-followed) location of
the C++/HIP compiler, so amdgpu-arch is found next to clang regardless
of the LLVM version (e.g. /usr/bin/clang++-N -> /usr/lib/llvm-N/bin).
Fall back to ${ROCM_PATH}/llvm and then ${ROCM_PATH} to preserve the
original behaviour on the /opt/rocm layout.		 Igor Luppi <igor.luppi@canonical.com> not-needed 2026-06-10

All known versions for source package 'rocm-hipamd'

Links