Details about CC env var and dpkgbuildpackage -a
I recently sent some patches to the lapack maintainer to get that
package to be cross-buildable:
A question came up that I would like some clarification on. The
maintainer had some other patches that use the CC env var to build the
project with clang instead of gcc, which in some ways conflicts with
- Currently I can ask for cross-building with either
But what happens when these two conflict? I.e. if on an amd64 box I
CC=gcc dpkg-buildpackage -armhf
I think the right answer is for dpkg-buildpackage to barf, which it
doesn't. This is a bug (or missing feature) in dpkg-buildpackage, yes?
- What about fortran? Similar conflict can happen with
F77=arm-linux-gnueabihf-gfortran CC=gcc dpkg-buildpackage
dpkg-buildpackage should complain?
I should always directly use $(DEB_HOST_GNU_TYPE)-gfortran right? I
don't think we have a fortran clang, but what if we did? How would one
decide to use it, and what executable should we call?
For lapack, I'm going to put this into debian/rules (unless somebody
here tells me otherwise):
# if we're cross-building and CC isn't explicitly set, set it to the
ifeq ($(origin CC),default)
CC := /usr/bin/$(DEB_HOST_GNU_TYPE)-cc
The reasoning is that the build system uses $(CC) to allow the user to
ask for clang via the environment. So we need to use CC too, but if the
then I need to set CC to the cross compiler. Is that invocation correct?
Is there some less boilerplaty way to get this functionality?