[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Some questions:

- Currently I can ask for cross-building with either

  CC=arm-linux-gnueabihf-gcc dpkg-buildpackage


  dpkg-buildpackage -aarmhf

  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
  # cross-compiler
  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
user invoked

  dpkg-buildpackage -aarmhf

then I need to set CC to the cross compiler. Is that invocation correct?
Is there some less boilerplaty way to get this functionality?


Reply to: