Commit Message

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

Comments

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

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).