[pkg-nvidia-devel] Bug#498499: Bug#498499: Using amd64 to compile the module into a i386 chroot

[Lennart Sorensen]

On Wed, Sep 10, 2008 at 04:27:01PM +0200, Jordi Pujol wrote:
> Package: nvidia-kernel-source
> Version: 173.14.09-5 and others
> Severity: normal
> 
> Hello,
> 
> when compiling a new kernel into an amd64 machine for the architecture i386 is 
> common to use a chroot to an i386 development environment,
> 
> in the nvidia-kernel-source package, some scripts detect the machine 
> architecture with the command "shell uname" of the main running kernel, and 
> therefore the compilation of the nvidia module is not successful,
> 
> with the little modifications attached in this message, the module compiles 
> correctly, 
> 
> The key idea is that the variable ARCH is already defined by the main 
> procedure, that is, in make-kpkg or m-a.
> 
> that is tested to successful compile in the i386 environment, with make-kpkg 
> and module-assistant also,
> 
> #make-kpkg -us -uc --initrd --verbose --append-to-version -686-jp1 --added-modules 
> nvidia-kernel --added-patches debianlogo  modules
> 
> #m-a -t build nvidia-kernel -k /usr/src/linux-2.6.26.5-686-jp1
> 
> Please use the attached patch,
> 
> Best Regards,
> 
> Jordi Pujol

> --- modules/nvidia-kernel/conftest.sh	2008-09-01 18:12:45.000000000 +0000
> +++ modules/nvidia-kernel.new/conftest.sh	2008-09-10 13:44:59.000000000 +0000
> @@ -34,7 +34,6 @@
>      CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS"
>  
>      if [ "$OUTPUT" != "$SOURCES" ]; then
> -        ARCH=`uname -m | sed -e 's/i.86/i386/'`
>          MACH_CFLAGS="-I$HEADERS/asm-$ARCH/mach-default"
>          if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then
>              MACH_CFLAGS="$MACH_CFLAGS -I$HEADERS/asm-x86/mach-default"
> --- modules/nvidia-kernel/debian/conf.mk	2008-09-01 18:12:45.000000000 +0000
> +++ modules/nvidia-kernel.new/debian/conf.mk	2008-09-10 13:44:45.000000000 +0000
> @@ -28,7 +28,6 @@
>  version="^Linux version [^(]* (.*@.*) (\(gcc.*\)) .*"
>  kernel_cc:=$(shell cat /proc/version | sed "s/"$(version)"/\1/")
>  
> -kernel_arch:=$(shell uname -m)
>  module_cc:=$(shell echo "$(module_cc)" | sed 's/.* \([0-9.]*\.[0-9]\).*/\1/')
>  kernel_cc:=$(shell echo "$(kernel_cc)" | sed 's/.* \([0-9.]*\.[0-9]\).*/\1/')
>  
> @@ -108,7 +107,7 @@
>  	if [ -f $(CURDIR)/debian/control.template ]; then \
>  		cp  $(CURDIR)/debian/control.template $(CURDIR)/debian/control; \
>  	fi
> -	if [ "$(kernel_arch)" = "x86_64" ]; then \
> +	if [ "$(ARCH)" = "x86_64" ]; then \
>  		cp $(CURDIR)/nv-kernel.o.x86_64 $(CURDIR)/nv-kernel.o ; \
>  	fi

Looks like a good idea to fix.

As a workaround you can use linux32 when you go into the chroot.  That
way everything will really think you have a 32bit system.

That is:
linux32 chroot /path/to/chroot

Then uname -m says i686 instead of x86_64.  I always do that for my
32bit chroot work, which might explain why I hadn't noticed that problem
either.

-- 
Len Sorensen