Re: Bug#1065439: dpkg-buildflags: add HIPFLAGS to supported flags
On Thu, Mar 07, 2024 at 04:00:22AM +0100, Guillem Jover wrote:
> > 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++.
>
> 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.
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).
> 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.
I think HIPFLAGS is the right way to go about this.
> > 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).
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
Reply to: