Cross compile rules update

Andy - have a look at the attached rules changes. This should allow for 
much faster ARM compiles and packaging using the Maverick arm cross 
compiler toolchain in universe. I've installed gcc-arm-linux-gnueabi by 
default in all of our Maverick x86'en schroots on the kernel team build 
machines.

This patch is against Maverick tip, but should likely be applied to the 
generic debian tree.

rtg

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

On Wed, Sep 29, 2010 at 10:00:48PM -0600, Tim Gardner wrote:
> Andy - have a look at the attached rules changes. This should allow
> for much faster ARM compiles and packaging using the Maverick arm
> cross compiler toolchain in universe. I've installed
> gcc-arm-linux-gnueabi by default in all of our Maverick x86'en
> schroots on the kernel team build machines.
> 
> This patch is against Maverick tip, but should likely be applied to
> the generic debian tree.
> 
> rtg
> -- 
> Tim Gardner tim.gardner@canonical.com

> The following changes since commit 34ff3203c626dda402f6570adaf120f47768e052:
>   Len Brown (1):
>         intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang
> 
> are available in the git repository at:
> 
>   git://kernel.ubuntu.com/rtg/ubuntu-maverick.git master
> 
> Tim Gardner (1):
>       UBUNTU: [Config] Add support for cross compiling armel
> 
>  debian/rules.d/0-common-vars.mk |   36 +++++++++++++++++++++++++++++++++++-
>  debian/rules.d/1-maintainer.mk  |    6 ++++++
>  debian/rules.d/2-binary-arch.mk |    2 +-
>  3 files changed, 42 insertions(+), 2 deletions(-)
> 
> From e23f7020f2adc74a6fc0d4560377e112954ddcd0 Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@canonical.com>
> Date: Wed, 29 Sep 2010 09:39:09 -0600
> Subject: [PATCH] UBUNTU: [Config] Add support for cross compiling armel
> 
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
>  debian/rules.d/0-common-vars.mk |   36 +++++++++++++++++++++++++++++++++++-
>  debian/rules.d/1-maintainer.mk  |    6 ++++++
>  debian/rules.d/2-binary-arch.mk |    2 +-
>  3 files changed, 42 insertions(+), 2 deletions(-)
> 
> diff --git a/debian/rules.d/0-common-vars.mk b/debian/rules.d/0-common-vars.mk
> index e03fa14..eddcd0d 100644
> --- a/debian/rules.d/0-common-vars.mk
> +++ b/debian/rules.d/0-common-vars.mk
> @@ -96,7 +96,32 @@ endif
>  # committing changes to the top level Makefile
>  SUBLEVEL	:= $(shell echo $(release) | awk -F. '{print $$3}')
>  
> -arch		:= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> +DEB_HOST_GNU_TYPE  = $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> +DEB_BUILD_GNU_TYPE = $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> +DEB_HOST_ARCH = $(shell dpkg-architecture -qDEB_HOST_ARCH)
> +DEB_BUILD_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH)
> +
> +#
> +# Detect invocations of the form 'fakeroot debian/rules binary arch=armel'
> +# within an x86'en schroot. This only gets you part of the way sicne the
> +# packaging phase fails, but you can at least compile the kernel quickly.
> +#
> +arch := $(DEB_HOST_ARCH)
> +ifneq ($(arch),$(DEB_HOST_ARCH))
> +	ifeq ($(arch),armel)
> +		cross_compile = CROSS_COMPILE=arm-linux-gnueabi-
> +	endif
> +endif
> +
> +#
> +# Detect invocations of the form 'dpk-buildpackage -B -aarmel' within
> +# an x86'en schroot. This is the only way to build all of the packages
> +# (except for tools).
> +#
> +ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
> +	cross_compile = CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)-
> +endif
> +
>  abidir		:= $(CURDIR)/$(DEBIAN)/abi/$(release)-$(revision)/$(arch)
>  prev_abidir	:= $(CURDIR)/$(DEBIAN)/abi/$(release)-$(prev_revision)/$(arch)
>  commonconfdir	:= $(CURDIR)/$(DEBIAN)/config
> @@ -198,3 +223,12 @@ kmake = make ARCH=$(build_arch) \
>  ifneq ($(LOCAL_ENV_CC),)
>  kmake += CC=$(LOCAL_ENV_CC) DISTCC_HOSTS=$(LOCAL_ENV_DISTCC_HOSTS)
>  endif
> +
> +ifneq ($(cross_compile),)
> +	#
> +	# Can't build the tools 'cause the make wants cross libraries and such.
> +	#
> +	do_tools=false
> +	kmake += $(cross_compile)
> +endif
> +
> diff --git a/debian/rules.d/1-maintainer.mk b/debian/rules.d/1-maintainer.mk
> index 7ad68dd..9713e3d 100644
> --- a/debian/rules.d/1-maintainer.mk
> +++ b/debian/rules.d/1-maintainer.mk
> @@ -109,6 +109,12 @@ endif
>  	@echo "do_tools                  = $(do_tools)"
>  	@echo "full_build                = $(full_build)"
>  	@echo "libc_dev_version		 = $(libc_dev_version)"
> +	@echo "DEB_HOST_GNU_TYPE         = $(DEB_HOST_GNU_TYPE)"
> +	@echo "DEB_BUILD_GNU_TYPE        = $(DEB_BUILD_GNU_TYPE)"
> +	@echo "DEB_HOST_ARCH             = $(DEB_HOST_ARCH)"
> +	@echo "DEB_BUILD_ARCH            = $(DEB_BUILD_ARCH)"
> +	@echo "arch                      = $(arch)"
> +	@echo "kmake                     = $(kmake)"
>  
>  printchanges:
>  	@baseCommit=$$(git log --pretty=format:'%H %s' | \
> diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk
> index 1d26496..ccb3fce 100644
> --- a/debian/rules.d/2-binary-arch.mk
> +++ b/debian/rules.d/2-binary-arch.mk
> @@ -277,7 +277,7 @@ binary-%: install-%
>  	dh_fixperms -p$(pkgimg)
>  	dh_installdeb -p$(pkgimg)
>  	dh_shlibdeps -p$(pkgimg)
> -	dh_gencontrol -p$(pkgimg)
> +	export DEB_BUILD_ARCH=$(arch) && export DEB_HOST_ARCH=$(arch) && dh_gencontrol -p$(pkgimg)
>  	dh_md5sums -p$(pkgimg)
>  	dh_builddeb -p$(pkgimg) -- -Zbzip2 -z9

I am slightly concerned that this one dh_ control needs the arch and
none of the others do.  Might we be better off exporting them at the
time they are defined; pretty sure there is a way to say that you want
that when you set the values.

Otherwise it does look saneish.  It is unfortuanate you need to zap the
tools unconditionally, perhaps we should leave that to the caller.

-apw

Tim,

if you installed a cross compiled kernel (let's ARM kernel), do you expect dkms installed modules to built fine *natively*? I recall seeing problems when building kernel modules when mixing cross and native compilation.

nicolas

> Andy - have a look at the attached rules changes. This should allow for
> much faster ARM compiles and packaging using the Maverick arm cross
> compiler toolchain in universe. I've installed gcc-arm-linux-gnueabi by
> default in all of our Maverick x86'en schroots on the kernel team build
> machines.
>
> This patch is against Maverick tip, but should likely be applied to the
> generic debian tree.
>
> rtg

Dunno. Right now I'm not really caring about DKMS packages, but I'm also 
not purposely trying to exclude them. I'm primarily searching for a way 
to allow kernel developers who do a lot of package builds to effectively 
simulate the native ARM build without actually having to use a QEMU 
emulated solution. If the binaries actually work, then thats just a 
bonus. The official archive released packages will continue to be built 
on native ARM build daemons.

rtg

On 09/30/2010 03:12 PM, Dechesne, Nicolas wrote:
> Tim,
>
> if you installed a cross compiled kernel (let's ARM kernel), do you
> expect dkms installed modules to built fine *natively*? I recall seeing
> problems when building kernel modules when mixing cross and native
> compilation.
>
> nicolas
>
>> Andy - have a look at the attached rules changes. This should allow for
>> much faster ARM compiles and packaging using the Maverick arm cross
>> compiler toolchain in universe. I've installed gcc-arm-linux-gnueabi by
>> default in all of our Maverick x86'en schroots on the kernel team build
>> machines.
>>
>> This patch is against Maverick tip, but should likely be applied to the
>> generic debian tree.
>>
>> rtg
>

The reason for (native) DKMS modules build failure using a cross-compiled
kernel is that the kernel build tools embedded in the kernel package (like
fixdep) are not built for ARM but for the host (x86 in my case), and fail
when called by native module building.

Any idea if / how this could be solved?

On Fri, Oct 1, 2010 at 5:36 PM, Tim Gardner <tim.gardner@canonical.com>wrote:

> Dunno. Right now I'm not really caring about DKMS packages, but I'm also
> not purposely trying to exclude them. I'm primarily searching for a way
> to allow kernel developers who do a lot of package builds to effectively
> simulate the native ARM build without actually having to use a QEMU
> emulated solution. If the binaries actually work, then thats just a
> bonus. The official archive released packages will continue to be built
> on native ARM build daemons.
>
> rtg
>
> On 09/30/2010 03:12 PM, Dechesne, Nicolas wrote:
> > Tim,
> >
> > if you installed a cross compiled kernel (let's ARM kernel), do you
> > expect dkms installed modules to built fine *natively*? I recall seeing
> > problems when building kernel modules when mixing cross and native
> > compilation.
> >
> > nicolas
> >
> >> Andy - have a look at the attached rules changes. This should allow for
> >> much faster ARM compiles and packaging using the Maverick arm cross
> >> compiler toolchain in universe. I've installed gcc-arm-linux-gnueabi by
> >> default in all of our Maverick x86'en schroots on the kernel team build
> >> machines.
> >>
> >> This patch is against Maverick tip, but should likely be applied to the
> >> generic debian tree.
> >>
> >> rtg
> >
>
>
> --
> Tim Gardner tim.gardner@canonical.com
>
> --
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>

On Mon, Oct 04, 2010, Jan, Sebastien wrote:
> The reason for (native) DKMS modules build failure using a cross-compiled
> kernel is that the kernel build tools embedded in the kernel package (like
> fixdep) are not built for ARM but for the host (x86 in my case), and fail
> when called by native module building.
> 
> Any idea if / how this could be solved?

 That means they ought to be built for both architectures and shipped in
 target cross-packages and in host packages (unless the tools are
 already provided in another host package already).