(-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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20110221020955.GB29661@elie
