Cross compile rules update
Loïc Minier
loic.minier at ubuntu.com
Thu Sep 30 12:37:45 UTC 2010
On Wed, Sep 29, 2010, Tim Gardner wrote:
> +ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
> + cross_compile = CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)-
> +endif
[...]
> +ifneq ($(cross_compile),)
> + kmake += $(cross_compile)
> +endif
This means you don't support CROSS_COMPILE in the environment anymore;
this is entirely correct for Debian style cross-builds, but it might
disappoint people who use the CS toolchains: these use a different
prefix, arm-none-linux-gnueabi-, or even arm-none-eabi-. In the Debian
cross scheme, this is not supposed to be supported, but nevertheless
you could try supporting it by doing:
ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
CROSS_COMPILE ?= $(DEB_HOST_GNU_TYPE)-
endif
ifneq ($(CROSS_COMPILE),)
kmake += CROSS_COMPILE=$(CROSS_COMPILE)
endif
> +ifneq ($(cross_compile),)
> + #
> + # Can't build the tools 'cause the make wants cross libraries and such.
> + #
> + do_tools=false
> +endif
So that's an opinionated decision on what you cross-compile. In
theory, these tools would cross-compile file, it's just that you lack
some pre-dependencies: cross-built versions of libdw and libelf.
I think we should aim at having cross-built packages as close as
possible to natively built packages, so I would suggest not setting
do_tools=false by default. However, I recognize that kernel developers
mostly cross-build as a time saver, and it's cumbersome to have to
cross-build libdw and libelf before cross-building the kernel (or to
import the native versions in the cross-build location).
Perhaps it would make more sense to keep "disable tools" as an
orthogonal option for people who only care to cross-compile the actual
kernel, and not the tools?
Developers could disable tools in DEB_BUILD_OPTIONS or when calling
rules; e.g.:
DEB_BUILD_OPTIONS=notools dpkg-buildpackage -aarmel
or:
DEB_BUILD_OPTIONS="do_tools=false"
or when calling rules directly:
debian/rules arch=armel do_tools=false
--
Loïc Minier
More information about the kernel-team
mailing list