#1065439 dpkg-buildflags: add HIPFLAGS to supported flags

#1065439#5
Date:
2024-03-04 17:59:36 UTC
From:
To:
Dear Maintainer,

When packaging the AMD ROCm GPU libraries for Debian, we are currently
using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if
they were written in C++.

This necessitates filtering out flags that are not supported when
building HIP language code. For example, the rocsparse d/rules include:

    export CXX=hipcc
    export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify optimize=-lto

    # filter incompatible options from affecting device code
    CXXFLAGS := $(subst -fstack-protector-strong,-Xarch_host -fstack-protector-strong,$(CXXFLAGS))
    CXXFLAGS := $(subst -fcf-protection,-Xarch_host -fcf-protection,$(CXXFLAGS))

In the lines above, we are prepending `-Xarch_host` to prevent certain
flags from being applied to device code (i.e., GPU code) while still
ensuring that they are applied to host code (i.e., CPU code).

However, there is HIP language support in CMake. We should use it!
dpkg-buildflags should set HIPFLAGS [1]. The CXXFLAGS make a good
starting place for the HIPFLAGS values, but `-Xarch_host` should be
added to `-fstack-protector-strong` and `-fcf-protection`, like in the
example above.

Sincerely,
Cory Bloor

[1]: https://cmake.org/cmake/help/v3.28/envvar/HIPFLAGS.html

#1065439#10
Date:
2024-03-07 03:00:22 UTC
From:
To:
Hi!

I guess we should also add HIPCXX (defaulting to <host-triplet>-hipcc
and HIPCXX_FOR_BUILD (defaulting to <build-triplet>-hipcc when cross
compiling, otherwise to hipcc) like with the other toolchains? An
apt-file query seems to indicate thee hipcc package provides no
triplet-qualified toolchains? Which means automatic cross-compiling
is going to be painful given our current infrastructure.

If support for this is really missing from the looks of it, we can
always postpone adding the compiler tool variables for now until this
is implemented (we can still add the HIPFLAGS variables though). I'm
CCing the debian-cross list for further insight.

It would be helpful if you could verify whether all flags currently
added to CXXFLAGS would work for HIPFLAGS. You can check for all such
instances by searching for either default_flags, @compiler_flags and
CXXFLAGS from:

  $ perldoc -m Dpkg::Vendor::Debian

Once we have the complete list, I'm happy to add the handling for
these flags in the code.

Thanks,
Guillem

#1065439#15
Date:
2024-03-07 06:35:35 UTC
From:
To:
I've tried to read a bit into their faq and my impression is that HIP
currently is x86_64-only and when it is not, the use of clang (which
notoriously refuse cooperating with cross building efforts) makes it
practically impossible to do any cross building. In essence, the HIP
ecosystem will opt out of cross building, but then the kind of software
that HIP targets requires beefy hardware where cross building isn't very
relevant, right? Just make sure to not require HIP for building HIP
(i.e. do not cause bootstrapping problems).

I think HIPFLAGS is the right way to go about this.

If dpkg were to provide HIPFLAGS, you could just export
CXXFLAGS:=$(HIPFLAGS).

Generally, reusing CXX in this way is a really bad idea on the upstream
side, but hardly preventable. It is very plausible to eventually have to
build an source package containing both C++ code and HIP code and then
you have no correct way of setting CXX. So from a dpkg point of view,
treating HIP as a new language with new variables makes most sense, but
it also means that source packages using these variables will have to do
the variable renaming themselves forever (and thus retaining the ability
to correctly scope those renames).

Helmut

#1065439#20
Date:
2025-07-27 22:45:46 UTC
From:
To:
Hello,

I've attached a patch with first rough attempt at specifying which flags
apply to HIPFLAGS. I have not tested this patch, but I have tested the
flags themselves. I'm trying to set all CXXFLAGS as HIPFLAGS except
-Werror=clobbered and all the LTO flags. I've also prepended -Xarch_host 
to all fsanitize flags [1], -fstack-protector-strong, and -fcf-protection.

Sincerely,
Cory Bloor

[1]: The -fsanitize=address flag works for some GPU targets, but it's
not clear to me how to limit it to supported GPU targets when dpkg
doesn't know what GPU targets are to be built. For this reason, I'm
limiting this flag to the host.