Cross compiled headers package breaks DKMS compilation

Vincent,

Could you please help us to do a testing?

Just remove all the faulty binaries which you listed here and try to native install/build your DKMS packages. To see whether it is works.

After some discussion with Andy and Tim, we think linux-header package should not ship those binaries and DKMS building will regenerate those binaries natively.

If it works, we probably need to check linux-header packaging later.

Thanks,
-Bryan

Hi Bryan,

Removing the binaries is not sufficient, I am affraid. DKMS build fails, and I have in make.log:

  /bin/sh: scripts/basic/fixdep: not found

Best regards,

V.

A precision: I removed the binaries manually under /usr/src/linux-headers-xxx.

Yeah, I wonder if it makes sense to package those scripts into the linux-header package. It's expected that those scripts are related with the builder's native arch, as it's used during the build. Don't know if removing these scripts could affect anything else then DKMS, but it sounds like that it'd be more correct to fix DKMS instead of cross build all the scripts and deploy that into the package.

I've added DKMS to this bug.

So from my point of view, it contains 2 parts of issue.

1. DKMS should not use those script to build kernel drivers when installing
2. kernel header package should not package those host native binaries.

Mario, could you please help me take a look at this?

Thanks,
-Bryan

@bryan: any chance this can be resurrected and/or fixed?

Is someone working on this problem? I'd much rather cross-compile on my quad-core x86_64 than natively build on my flash-mounted little Pandaboard.

There is one more option: we can cross compile all those binaries after kernel/modules are built so they will be proper arch. This will require adding one more task to debian/rules.

because of the same problem, cross building a kernel pkg prevents the use of systemtap tool at run time (systemtap, like dkms is building kernel modules).

so another good reason to get this fixed...

DKMS isn't the only package that will run into problems, really hand compiling kernel modules will probably hit the same roadblocks.

I think the most appropriate solution is to fix these packages before they're deployed on the cross compiled architectures. It doesn't make sense to have binaries from the native builder on those machines. Those last files should be recompiled for the correct target architecture at the end of the build process after they're used on the machine to cross compile all modules.

Avik, you'll probably hit this bug if you try Systemtap (or any other dkms package) with a kernel package that was built using the cross toolchain. To properly fix it sync with Marcin and John, they should know exactly what are the needed changes at the kernel package.

Fixed at the linaro kernel by:
- http://git.linaro.org/gitweb?p=ubuntu/linux-linaro-oneiric.git;a=commit;h=4f0dffd7e2166fd92e3551b8223728028ad62e2b
- http://git.linaro.org/gitweb?p=ubuntu/linux-linaro-oneiric.git;a=commit;h=d527e6b5747390f52f11893dd8fd95cd05fe6ccb

the Oneiric's omap4 kernel has both (d18a6e2590dcde348e7ece6f5e2d76085663413b and c0c8c506279cf07c303c54117bcca37f0d5bcfd5).

Checking out bca641b96bb12e4d892ad10498c7877e14d24abc

Author: Paolo Pisati <email address hidden>
Date: Wed Dec 14 17:23:24 2011 +0100

    UBUNTU: Ubuntu-3.0.0-1206.14

and cross compiling on an x86_64 for omap4 as, for example,

CROSS_COMPILE=arm-linux-gnueabi- do_tools=false dpkg-buildpackage -B -aarmel -uc -us

I am still left with x86_64 scripts as opposed to ARM executables causing DKMS issues installing the header package.

I see that the KBUILD_SCRIPTROOT "fix" was reverted.

commit d3cefbb1062fc018a476190043e76f680bf5e2f0
Author: Tim Gardner <email address hidden>
Date: Mon Nov 7 17:50:52 2011 +0000

    Revert "LINARO: Use KBUILD_SCRIPTROOT to cross build scripts"

    This reverts commit d18a6e2590dcde348e7ece6f5e2d76085663413b.

    Breaks cross compile in Oneiric x86 chroots.

With some persuasion, doing something along the lines of

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KERNELVERSION=3.0.0-1206-omap4 CONFIG_DEBUG_SECTION_MISMATCH=y KBUILD_BUILD_VERSION="14" LOCALVERSION= localver-extra= O=<header_package_path> HOSTCC=arm-linux-gnueabi-gcc KBUILD_SCRIPTROOT=<build_omap4 path> -j1 silentoldconfig prepare scripts

seems to successfully build the ARM scripts. But that required me to make some edits to the make files.

Is this indeed still broken? Or am I missing the correct incantation for executing the cross compile?

Apoogies for the duplication, this is more accurately the package I am looking at.

Checking out bca641b96bb12e4d892ad10498c7877e14d24abc

Author: Paolo Pisati <email address hidden>
Date: Wed Dec 14 17:23:24 2011 +0100

    UBUNTU: Ubuntu-3.0.0-1206.14

and cross compiling on an x86_64 for omap4 as, for example,

CROSS_COMPILE=arm-linux-gnueabi- do_tools=false dpkg-buildpackage -B -aarmel -uc -us

I am still left with x86_64 scripts as opposed to ARM executables causing DKMS issues installing the header package.

I see that the KBUILD_SCRIPTROOT "fix" was reverted.

commit d3cefbb1062fc018a476190043e76f680bf5e2f0
Author: Tim Gardner <email address hidden>
Date: Mon Nov 7 17:50:52 2011 +0000

    Revert "LINARO: Use KBUILD_SCRIPTROOT to cross build scripts"

    This reverts commit d18a6e2590dcde348e7ece6f5e2d76085663413b.

    Breaks cross compile in Oneiric x86 chroots.

With some persuasion, doing something along the lines of

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KERNELVERSION=3.0.0-1206-omap4 CONFIG_DEBUG_SECTION_MISMATCH=y KBUILD_BUILD_VERSION="14" LOCALVERSION= localver-extra= O=<header_package_path> HOSTCC=arm-linux-gnueabi-gcc KBUILD_SCRIPTROOT=<build_omap4 path> -j1 silentoldconfig prepare scripts

seems to successfully build the ARM scripts. But that required me to make some edits to the make files.

Is this indeed still broken? Or am I missing the correct incantation for executing the cross compile?

diff --git a/debian/rules.d/2-binary-arch.mk b/debian/rules.d/2-binary-arch.mk
index 1b26a39..eb9fa5a 100644
--- a/debian/rules.d/2-binary-arch.mk
+++ b/debian/rules.d/2-binary-arch.mk
@@ -175,7 +175,13 @@ endif
                sed -e 's/.*CONFIG_DEBUG_INFO=.*/# CONFIG_DEBUG_INFO is not set/
                $(hdrdir)/.config
        chmod 644 $(hdrdir)/.config
+ifeq ($(CROSS_COMPILE),)
        $(kmake) O=$(hdrdir) -j1 silentoldconfig prepare scripts
+else
+ $(kmake) HOSTCC=$(CROSS_COMPILE)gcc \
+ KBUILD_SCRIPTROOT=$(builddir)/build-$* O=$(hdrdir) \
+ -j1 silentoldconfig prepare scripts
+endif
        # We'll symlink this stuff
        rm -f $(hdrdir)/Makefile
        rm -rf $(hdrdir)/include2