Re: Bug#594179: dpkg armhf patch acceptance status?
(-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
Reply to: