Comment 12 for bug 238259

Revision history for this message
undefined (undefined) wrote :

SHORT ANSWER:
apt-get install virtualbox-ose-source linux-headers-$(uname -r)
BUILD_TARGET_ARCH=amd64 m-a -k /usr/src/linux-headers-$(uname -r) build virtualbox-ose
dpkg -i /usr/src/virtualbox-ose-modules-$(uname -r)_*_amd64.deb

LONG ANSWER:
the problem, at least for virtualbox-ose-source 1.5.6-dfsg-6ubuntu1 in hardy, is that debian/rules (lines 38-48) does not set ARCH correctly (ie ARCH set to "i386" instead of "x86_64"). see attached patch for possible fix.

on all my amd64 machines (two running debian etch and one running ubuntu hardy; linux 2.6.22, 2.6.26, and 2.6.24 respectively) "uname -m" returns "x86_64". so line 40 (grep 86) evaluates to true and ARCH is set to i386. neither of the two remaining tests (lines 43 & 46) are true because module-assistant sets KVERS to "2.6.24-22-generic" which doesn't contain the architecture as a substring (ie "86" or "amd64"). so the binary-modules rule calls the module's Makefile with ARCH=i386.

in the module's Makefile, on lines 18-40, if BUILD_TARGET_ARCH is not already set, then ARCH (and "uname -m" if ARCH is not set, but not applicable in our case) is used to set BUILD_TARGET_ARCH. since ARCH=i386 is passed to the Makefile by debian/rules, the Makefile sets the BUILD_TARGET_ARCH to x86. this eventually defines RT_ARCH_X86 in the Makefile which causes 32-bit i386 assembly to be compiled with SUPDRVShared.c (unsuccessfully with 64-bit amd64 assembler) which causes the error and halts the build.

because in the Makefile BUILD_TARGET_ARCH is tested before ARCH and debian/rules does not set BUILD_TARGET_ARCH, but ARCH, my hack is to define BUILD_TARGET_ARCH (as "amd64") when calling module-assistant. but the more proper solution is to have debian/rules properly recognize the arch from "uname -m".