On Fri, 2016-09-02 at 16:49 +0100, Ben Hutchings wrote: > On Fri, 2016-09-02 at 03:35 -0700, Jose R Rodriguez wrote: > > > > Niltze, all! > > > > Currently running Reiser4-patched kernel 4.7 built from pristine > > source upstream: > > > > Linux mictlantecuhtli 4.7.0.tezcatlipoca #1 SMP PREEMPT Wed Aug 10 > > 05:04:17 PDT 2016 x86_64 GNU/Linux > > > > On the other hand, I have experienced multiple issues building > > Debian'ized kernel 4.7.2-1 -- first building on Jessie modified for > > GCC 4.9; > > and then attempting build on Jessie-built GCC 5.3. And finally I > > attempted the build on Debian Unstable and it failed, as well. > > Below are the offending sections -- which, by the way -- roughly > > correspond in all instances of Debian and GCC: > [...] > > This happens if you invoke debian/rules directly and not through dpkg- > buildpackage. Rather, it can happen in some circumstances, but... > debian/rules.real does: > > ifdef OVERRIDE_HOST_TYPE > CROSS_COMPILE := $(OVERRIDE_HOST_TYPE)- > else ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) > CROSS_COMPILE := $(DEB_HOST_GNU_TYPE)- > else > CROSS_COMPILE := > endif > > So the assumption is that all those architecture variables, or none, > are defined. dpkg-buildpackage does define them all. > > However, debian/rules does: > > DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) > > and does not define any other architecture variables. ...variable definitions in debian/rules don't automatically propagate to debian/rules.real, so this doesn't explain the failure. And although I have seen this failure myself, I can't reproduce it now. > We should probably include /usr/share/dpkg/architecture.mk in > debian/rules instead. I now think it should be included in debian/rules.real. However, until I have a way to reproduce the problem, I'm not going to attempt a fix. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part