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".
SHORT ANSWER: ose-source linux-headers- $(uname -r) ARCH=amd64 m-a -k /usr/src/ linux-headers- $(uname -r) build virtualbox-ose virtualbox- ose-modules- $(uname -r)_*_amd64.deb
apt-get install virtualbox-
BUILD_TARGET_
dpkg -i /usr/src/
LONG ANSWER: 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.
the problem, at least for virtualbox-
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".