Bug#773065: selecting target via dpkg-buildpackage --target-arch

[Helmut Grohne]

Package: src:gcc-4.9
Version: 4.9.2-7
Tags: patch
User: hel...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian...@lists.debian.orgj

Please allow selecting the target architecture using "dpkg-buildpackage
--target-arch" again. This ability was removed in 4.9.2-7 when #768167
was fixed.

I am attaching a diff that enables target selection via:
* dpkg-buildpackage --target-arch
* debian/target
* DEB_GCC_TARGET

Please see below for the rationale for individual hunks.

Helmut

diff -u gcc-4.9-4.9.2/debian/rules.defs gcc-4.9-4.9.2/debian/rules.defs
--- gcc-4.9-4.9.2/debian/rules.defs
+++ gcc-4.9-4.9.2/debian/rules.defs
@@ -31,23 +31,7 @@
# for rules.sonames
vafilt_defined = 1

-dpkg_target_vars := $(shell (dpkg-architecture | grep -q DEB_TARGET) && echo yes)
-ifeq ($(dpkg_target_vars),yes)
- DEB_TARGET_ARCH=
- DEB_TARGET_ARCH_BITS=
- DEB_TARGET_ARCH_CPU=
- DEB_TARGET_ARCH_ENDIAN=
- DEB_TARGET_ARCH_OS=
- DEB_TARGET_GNU_CPU=
- DEB_TARGET_GNU_SYSTEM=
- DEB_TARGET_GNU_TYPE=
- DEB_TARGET_MULTIARCH=
-endif
-
DPKG_VARS := $(shell dpkg-architecture)
-ifeq ($(dpkg_target_vars),yes)
- DPKG_VARS := $(filter-out DEB_TARGET_%, $(DPKG_VARS))
-endif
DEB_BUILD_ARCH ?= $(call vafilt,$(DPKG_VARS),DEB_BUILD_ARCH)
DEB_BUILD_GNU_TYPE ?= $(call vafilt,$(DPKG_VARS),DEB_BUILD_GNU_TYPE)
DEB_BUILD_MULTIARCH ?= $(call vafilt,$(DPKG_VARS),DEB_BUILD_MULTIARCH)

Explicitly clearing DEB_TARGET_ variables is not needed as they are set
later. Having them cleared prevents selection via dpkg-buildpackage
--target-arch. Furthermore, clearing DEB_TARGET_ assignments from
DPKG_VARS is not necessary, because those are never accessed using
vafilt.

@@ -97,7 +81,7 @@

# ---------------------------------------------------------------------------
# set target
-# - GNU triplet via DEB_TARGET_GNU_TYPE
+# - dpkg-buildpackage --target-arch (via DEB_TARGET_ARCH)
# - Debian arch in debian/target
# - Debian arch via DEB_GCC_TARGET or GCC_TARGET
#
@@ -105,39 +89,35 @@
ifdef GCC_TARGET
DEB_GCC_TARGET := $(GCC_TARGET)
endif
-ifdef DEB_TARGET_GNU_TYPE
- TARGET_VARS := $(shell dpkg-architecture -f -t$(DEB_TARGET_GNU_TYPE) 2>/dev/null)
-else
- # allow debian/target to be used instead of DEB_GCC_TARGET - this was requested
- # by toolchain-source maintainer
- DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2>/dev/null)))
- ifndef DEB_TARGET_ARCH
- ifneq (,$(DEBIAN_TARGET_FILE))
- DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE)
- else
- ifdef DEB_GCC_TARGET
- DEB_TARGET_ARCH := $(DEB_GCC_TARGET)
- else
- DEB_TARGET_ARCH := $(DEB_HOST_ARCH)
- endif
+# since dpkg 1.17.14, DEB_TARGET_* default to DEB_HOST_*
+DEB_TARGET_ARCH ?= $(DEB_HOST_ARCH)
+# allow debian/target to be used instead of DEB_GCC_TARGET - this was requested
+# by toolchain-source maintainer
+DEBIAN_TARGET_FILE := $(strip $(if $(wildcard debian/target),$(shell cat debian/target 2>/dev/null)))
+# consider DEB_TARGET_* set, if it differs from DEB_HOST_*
+ifeq ($(DEB_TARGET_ARCH),$(DEB_HOST_ARCH))
+ ifneq (,$(DEBIAN_TARGET_FILE))
+ DEB_TARGET_ARCH := $(DEBIAN_TARGET_FILE)
+ else
+ ifdef DEB_GCC_TARGET
+ DEB_TARGET_ARCH := $(DEB_GCC_TARGET)
endif
endif

Rather than checking DEB_TARGET_GNU_TYPE, I check DEB_TARGET_ARCH here.
The reason for this is that the only way to determine whether a
DEB_TARGET_* variable was actually set is to compare it to the
DEB_HOST_* counterpart. But DEB_HOST_GNU_TYPE is munged for i386, so on
a i386 build system, DEB_TARGET_GNU_TYPE can differ from
DEB_HOST_GNU_TYPE without being set. Thus this patch does not examine
DEB_HOST_GNU_TYPE at all.

Not supporting DEB_TARGET_GNU_TYPE is not a regression in this patch, as
4.9.2-7 already removed that support. If it needs to be supported
anyway, the major alternative to this approach is to prefer
debian/target and DEB_GCC_TARGET over DEB_TARGET_GNU_TYPE and hope that
it doesn't break the native build on i386.

The order of preference implemented in this patch is:
* dpkg-buildpackage --target-arch (via DEB_TARGET_ARCH)
* debian/target
* DEB_GCC_TARGET

I verified that each of those methods works after applying this patch.

- TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2>/dev/null)
-endif
-ifeq ($(dpkg_target_vars),yes)
- TARGET_VARS := $(filter-out DEB_TARGET_%, $(TARGET_VARS))
endif
+TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2>/dev/null)

Again, no clearing of TARGET_VARS is necessary, because the DEB_TARGET_*
variables are not accessed using vafilt.

DEB_TARGET_ARCH := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH)
+DEB_TARGET_ARCH_BITS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_BITS)
DEB_TARGET_ARCH_OS := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_OS)
DEB_TARGET_ARCH_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_CPU)
+DEB_TARGET_ARCH_ENDIAN := $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH_ENDIAN)
DEB_TARGET_GNU_CPU := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_CPU)
DEB_TARGET_GNU_TYPE := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_TYPE)
DEB_TARGET_GNU_SYSTEM := $(call vafilt,$(TARGET_VARS),DEB_HOST_GNU_SYSTEM)

Explicitly set the remaining DEB_TARGET_* variables to prevent their
original values from leaking into the build. If they were used in any
place, it would be rather confusing to find out that they were leaks
from the host architecture.

[Matthias Klose]

Control: tags -1 + moreinfo

On 12/13/2014 10:55 PM, Helmut Grohne wrote:
> Package: src:gcc-4.9
> Version: 4.9.2-7
> Tags: patch
> User: hel...@debian.org
> Usertags: rebootstrap
> X-Debbugs-Cc: debian...@lists.debian.orgj
>
> Please allow selecting the target architecture using "dpkg-buildpackage
> --target-arch" again. This ability was removed in 4.9.2-7 when #768167
> was fixed.
>
> I am attaching a diff that enables target selection via:
> * dpkg-buildpackage --target-arch
> * debian/target
> * DEB_GCC_TARGET

please verify your patch using an old dpkg from wheezy, using native builds and
the supported cross builds and attach the four compressed build logs.


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Helmut Grohne]

Control: tags -1 - moreinfo

On Tue, Dec 16, 2014 at 01:37:12PM +0100, Matthias Klose wrote:
> please verify your patch using an old dpkg from wheezy, using native builds and
> the supported cross builds and attach the four compressed build logs.

I have some problems making sense of this, please clarify:

You are asking me to use an old dpkg. But dpkg-architecture (which is
what sets DEB_TARGET_ARCH) is in dpkg-dev. So I am assuming that you did
mean dpkg-dev here. Do you confirm?

When downgrading dpkg-dev to wheezy, any build finishes rather quickly:

| dpkg-checkbuilddeps: Unmet build dependencies: dpkg-dev (>= 1.17.11)

Builds with wheezy dpkg-dev simply are not supported by the packaging.
Likely, this is not what you wanted to know.

You are mentioning four logs, but I have problems understanding which
configurations you are asking for. From your two lines, I'd suppose you
are asking for:

* host=build=target=amd64 (for example) in a sid chroot with dpkg-dev
downgraded to wheezy. (Fails as above.)
* host=build=amd64 target=x32 with the supported cross build method in
a sid chroot with dpkg-dev downgraded to wheezy and selecting the
target via debian/target. (Build-Depends not installable, because
#771497.)

So this is two builds, but you asked for four. Which ones am I missing?

Please clarify and re-add the moreinfo tag.

Thanks in advance

Helmut

[Matthias Klose]

Control: tags -1 + moreinfo

On 12/16/2014 07:58 PM, Helmut Grohne wrote:
> Control: tags -1 - moreinfo
>
> On Tue, Dec 16, 2014 at 01:37:12PM +0100, Matthias Klose wrote:
>> please verify your patch using an old dpkg from wheezy, using native builds and
>> the supported cross builds and attach the four compressed build logs.
>
> I have some problems making sense of this, please clarify:

if you have some problems, then please don't play bts ping pong. the build logs
are not yet attached.

> You are asking me to use an old dpkg. But dpkg-architecture (which is
> what sets DEB_TARGET_ARCH) is in dpkg-dev. So I am assuming that you did
> mean dpkg-dev here. Do you confirm?
>
> When downgrading dpkg-dev to wheezy, any build finishes rather quickly:
>
> | dpkg-checkbuilddeps: Unmet build dependencies: dpkg-dev (>= 1.17.11)
>
> Builds with wheezy dpkg-dev simply are not supported by the packaging.
> Likely, this is not what you wanted to know.

surely you did regenerate the control file for the wheezy build.

> You are mentioning four logs, but I have problems understanding which
> configurations you are asking for. From your two lines, I'd suppose you
> are asking for:
>
> * host=build=target=amd64 (for example) in a sid chroot with dpkg-dev
> downgraded to wheezy. (Fails as above.)

yes, this called native.

> * host=build=amd64 target=x32 with the supported cross build method in
> a sid chroot with dpkg-dev downgraded to wheezy and selecting the
> target via debian/target. (Build-Depends not installable, because
> #771497.)

sure, fix it.

>
> So this is two builds, but you asked for four. Which ones am I missing?

these two using the old and the new dpkg.

[Helmut Grohne]

Control: reopen -1
Control: reassign -1 src:gcc-6

On Tue, Sep 20, 2016 at 10:19:12PM +0000, Debian Bug Tracking System wrote:
> Please allow selecting the target architecture using "dpkg-buildpackage
> --target-arch" again. This ability was removed in 4.9.2-7 when #768167
> was fixed.
>
> I am attaching a diff that enables target selection via:
> * dpkg-buildpackage --target-arch
> * debian/target
> * DEB_GCC_TARGET

As far as I can tell, the issue is still present in later versions and
a rebased patch is available from cross-gcc-dev (e.g.
http://sources.debian.net/src/cross-gcc/101/patches/gcc-6/0006-Allow-target-selection-via-dpkg-buildpackage-target-.patch/).

Thus reopening.

Helmut