Re: Bug#594179: dpkg armhf patch acceptance status?

[Jonathan Nieder <jrnieder@gmail.com>]

(-cc: the bug because I have nothing major to add at the moment.
 Please cc me on replies.)
Wookey wrote:

> Guillem makes some good points about how GNU triplets should (and once
> did) represent ABIs, and that if they still did, dpkg (and everything
> else) could use them as the definitive ABI-indicator. He's quite
> right. 
[...]
> But it is also the case that a given toolchain can produce binaries of
> different ABIs, so there is logic in the GCC argument that the triplet
> denotes a toolchain, not (necessarily) an ABI. (e.g arm-linux-gnueabi
> toolchain can produce armel and armhf binaries (and in fact there are
> more incompatible ABIs it could spit out, but we're not trying to make
> distros out of those).

Thanks for this explanation!  It helps a lot.

That leaves two remaining questions:

 - can each Debian arch have a distinct toolchain?  If not, why not
   (since it would be very convenient to use)?

>>   ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
>>     confflags += --build $(DEB_HOST_GNU_TYPE)
>>   else
>>     confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
>>   endif
[...]
> Yes, this is potentially a pain in the bum. We need to select a
> toolchain (which could be 'arm-linux-gnueabi' for both arm port
> targets, but with different default options

 - how do we communicate distinct compiler flags for the build and host
   machines to packages, with a minimum of disruption to existing
   packaging?  Maybe dpkg-buildflags needs to distinguish between
   --build and --host flags, so that dh_auto_configure et al can pass
   HOST_CFLAGS to configure.

Jonathan