Bug#768167: dpkg-architecture export DEB_TARGET_* make cross build failure
Control: retitle -1 target architecture no longer selectable via debian/target or DEB_GCC_TARGET
On Thu, Nov 06, 2014 at 12:15:13AM +0800, YunQiang Su wrote:
> But now, when DEB_TARGET_GNU_TYPE and DEB_TARGET_ARCH always define,
> we can not get cross complier with debian/target file or DEB_GCC_TARGET var.
Is there a strong reason to keep supporting target selection via
debian/target or DEB_GCC_TARGET? It seems that the packaging can be
simplified by removing these alternatives.
This regression was introduced in dpkg version 1.17.14 (one month ago):
| * dpkg-architecture:
| - Add support for target system information via the new DEB_TARGET_ family
| of variables, and new -A and -T options to override defaulting to the
| host system.
| - Clarify that -a, -t, -e and -i work with the host system.
dpkg-buildpackage exports all variables read from dpkg-buildpackage.
When only setting DEB_TARGET_ARCH, dpkg-architecture would notice that
the DEB_TARGET_* variables are inconsistent and reset them to defaults.
Setting the whole family of DEB_TARGET_* variables makes
dpkg-architecture not touch them.
As remedy the --target-arch option was added to dpkg-buildpackage in
dpkg version 1.17.17:
| * Add support for --host-arch, --host-type, --target-arch and --target-type
| long options in dpkg-buildpackage. These will get passed through to
| dpkg-architecture. This restores the ability to specify the target
| architecture when building cross-compilers. Regression introduced in
| dpkg 1.17.14. Reported by Helmut Grohne <helmut@subdivi.de>.
It seems to me that dpkg-buildpackage --target-arch is the way to go. So
what are the reasons to keep supporting the alternatives? It seems
unlikely the proposed changes are eligible for a jessie unblock. Is
--target-arch good enough for you?
Helmut
Reply to: