Cross compiled headers package breaks DKMS compilation

Bug #666267 reported by Vincent Stehlé on 2010-10-25
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
DKMS
Undecided
Unassigned
Linaro Ubuntu
Medium
Avik Sil
linux-linaro-mx51 (Ubuntu)
Undecided
Unassigned
linux-ti-omap4 (Ubuntu)
Medium
Bryan Wu

Bug Description

When cross-compiling headers package on a PC, some x86 programs get shipped in the .deb.
Those programs get called during later compilation of DKMS modules, breaking the build.

Faulty binaries are:

  scripts/mod/mk_elfconfig
  scripts/mod/modpost
  scripts/kconfig/conf
  scripts/basic/hash
  scripts/basic/docproc
  scripts/basic/fixdep
  scripts/bin2c
  scripts/kallsyms
  scripts/pnmtologo
  scripts/conmakehash
  scripts/selinux/genheaders/genheaders
  scripts/selinux/mdp/mdp

Starting with, for example:

  https://launchpad.net/ubuntu/+archive/primary/+files/linux-ti-omap4_2.6.35.orig.tar.gz
  https://launchpad.net/ubuntu/+archive/primary/+files/linux-ti-omap4_2.6.35-903.16.diff.gz
  https://launchpad.net/ubuntu/+archive/primary/+files/linux-ti-omap4_2.6.35-903.16.dsc

Extract with 'dpkg-source -x linux-ti-omap4_2.6.35-903.16.dsc'.
Cross compilation is done with:

  fakeroot debian/rules clean
  export $(dpkg-architecture -aarmel)
  CROSS_COMPILE=arm-linux-gnueabi- skipabi=true skipmodule=true fakeroot debian/rules binary-omap4

To obtain cross compilers, add the following line to your '/etc/apt/sources.list':

  deb http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ./

Then install 'gcc-4.4-arm-linux-gnueabi'.
After cross build, the resulting .deb are:

  linux-headers-2.6.35-903-omap4_2.6.35-903.16_armel.deb
  linux-image-2.6.35-903-omap4_2.6.35-903.16_armel.deb

One can check the shipped x86 binaries by extracting the .deb:

  dpkg -x linux-headers-2.6.35-903-omap4_2.6.35-903.16_armel.deb extract

...and searching for x86 executables:

  find extract/usr/src/linux-headers-2.6.35-903-omap4/scripts -type f -exec file "{}" \; |grep ELF |grep x86 |sed 's,:.*,,'

Some more details on cross compiling can be found at 'http://idlethread.blogspot.com/2009/01/recipe-of-day-cross-compiling-armel.html'.

Bryan Wu (cooloney) on 2010-10-25
Changed in linux-ti-omap4 (Ubuntu):
importance: Undecided → Medium
assignee: nobody → Bryan Wu (cooloney)
Bryan Wu (cooloney) wrote :

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

Vincent Stehlé (vstehle) wrote :

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.

Vincent Stehlé (vstehle) wrote :

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

Ricardo Salveti (rsalveti) wrote :

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.

Bryan Wu (cooloney) wrote :

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

Nicolas Dechesne (ndec) wrote :

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

Alison Chaiken (alchaiken) wrote :

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.

Marcin Juszkiewicz (hrw) wrote :

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.

Nicolas Dechesne (ndec) wrote :

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

Mario Limonciello (superm1) wrote :

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.

Changed in dkms:
status: New → Won't Fix
Ricardo Salveti (rsalveti) wrote :

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.

Changed in linaro-ubuntu:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Avik Sil (aviksil)
milestone: none → 11.09
Paolo Pisati (p-pisati) wrote :

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

Changed in linux-ti-omap4 (Ubuntu):
status: New → Fix Released

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

Changed in linux-ti-omap4 (Ubuntu):
status: Fix Released → Confirmed
Paolo Pisati (p-pisati) on 2012-03-23
Changed in linux-ti-omap4 (Ubuntu):
status: Confirmed → Fix Committed
Paolo Pisati (p-pisati) on 2012-03-28
Changed in linux-ti-omap4 (Ubuntu):
status: Fix Committed → Fix Released
John Rigby (jcrigby) on 2012-08-11
Changed in linux-linaro-mx51 (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers