allow 32-bit module build on 64-bit host

[Alex Chiang]

Binary package hint: dkms

If you attempt to build a 32-bit module in a 32-bit chroot on a 64-bit buildd host, you will encounter build errors such as these:

ld: Relocatable linking with relocations from format elf64-x86-64 (/var/lib/dkms/compat-wireless-ath9k-htc/2.6.36-rc2-1ubuntu1/build/drivers/net/wireless/ath/ath9k/eeprom_def.o) to format elf32-i386 (/var/lib/dkms/compat-wireless-ath9k-htc/2.6.36-rc2-1ubuntu1/build/drivers/net/wireless/ath/ath9k/ath9k_hw.o) is not supported

Note that dkms_common.postinst does detect the target arch correctly and passes it to dkms build:

+ echo Building for architecture i686
Building for architecture i686
+ ARCH=-a i686
[...]
+ echo Building initial module for 2.6.32-22-generic
Building initial module for 2.6.32-22-generic
+ dkms build -m compat-wireless-ath9k-htc -v 2.6.36-rc2-1ubuntu1 -k 2.6.32-22-generic -a i686

We need to instruct the kernel Makefile to use the 32-bit toolchain on the build host, which can be done with the attached patch.

[Mario Limonciello (superm1)]

I'm not convinced this patch is correct. What if you are building an i686 kernel? You shouldn't be applying i386 in that scenario.

[Alex Chiang (achiang)]

i686 is 32 bit, so yes, you would want to pass i386 in that
scenario.

Only x86_64 is recognized as 64-bit.

If it will reduce confusion for future maintainers, you could
s/i386/x86/ in that patch.

The kernel Makefile recognizes both "i386" and "x86" as "do a
32-bit build".

[Mario Limonciello (superm1)]

However some distros do support an i386 or i686 kernel build. I'm thinking
RHEL specifically.

On Wed, Oct 6, 2010 at 11:44, Alex Chiang <email address hidden> wrote:

> i686 is 32 bit, so yes, you would want to pass i386 in that
> scenario.
>
> Only x86_64 is recognized as 64-bit.
>
> If it will reduce confusion for future maintainers, you could
> s/i386/x86/ in that patch.
>
> The kernel Makefile recognizes both "i386" and "x86" as "do a
> 32-bit build".
>
> --
> allow 32-bit module build on 64-bit host
> https://bugs.launchpad.net/bugs/655275
> You received this bug notification because you are subscribed to dkms in
> ubuntu.
>

--
Mario Limonciello
<email address hidden>

[Mario Limonciello (superm1)]

As mentioned in IRC w/ tseliot,

it's better to pass the right argument for the architecture from the
template than it is to add individual hacks along the way.

On Wed, Oct 6, 2010 at 11:54, Mario Limonciello <email address hidden> wrote:

> However some distros do support an i386 or i686 kernel build. I'm thinking
> RHEL specifically.
>
>
> On Wed, Oct 6, 2010 at 11:44, Alex Chiang <email address hidden> wrote:
>
>> i686 is 32 bit, so yes, you would want to pass i386 in that
>> scenario.
>>
>> Only x86_64 is recognized as 64-bit.
>>
>> If it will reduce confusion for future maintainers, you could
>> s/i386/x86/ in that patch.
>>
>> The kernel Makefile recognizes both "i386" and "x86" as "do a
>> 32-bit build".
>>
>> --
>> allow 32-bit module build on 64-bit host
>> https://bugs.launchpad.net/bugs/655275
>> You received this bug notification because you are subscribed to dkms in
>> ubuntu.
>>
>
>
>
> --
> Mario Limonciello
> <email address hidden>
>

--
Mario Limonciello
<email address hidden>

[Alex Chiang (achiang)]

Ok, I checked with mjg59.

He says that the only difference between 386/586/686 flavors of RHEL is the kernel config, which leads to different compiler optimizations. The ARCH string has nothing to do with that.

So passing either "i386" or "x86" to force a 32-bit build is perfectly safe, even for RHEL.

Alternatively, you could just read the top-level kernel Makefile and search for "uname -m". You'll see what we do with SUBARCH and ARCH; a little further down, you can see the x86-specific section for SRCARCH.

I think the patch might break if we try to build a 64-bit module on a 32-bit host, I haven't tested that combo; but it should be extremely rare anyway.

[Alex Chiang (achiang)]

Mario,

This bug has been sitting for a while, and I'd like to learn if you still have any objections to the proposed patch (and if so, why?).

Thanks!

[Mario Limonciello (superm1)]

Alex,

Is this still actually necessary? I just made an attempt to reproduce your problem in a 32 bit natty chroot from a 64 bit lucid box using DKMS master as of today with a simple kernel module (nvidiabl) and couldn't reproduce it.

supermario@serverman:~$ uname -a
Linux serverman 2.6.32-31-server #61-Ubuntu SMP Fri Apr 8 19:44:42 UTC 2011 x86_64 GNU/Linux
supermario@serverman:~$ schroot -uroot -c natty-i386
(natty-i386)root@serverman:/home/supermario# dpkg -i dkms_2.2.0.1-0_all.deb
Selecting previously deselected package dkms.
(Reading database ... 13981 files and directories currently installed.)
Unpacking dkms (from dkms_2.2.0.1-0_all.deb) ...
Setting up dkms (2.2.0.1-0) ...
(natty-i386)root@serverman:/home/supermario# cp nvidia_bl-0.69-1/ /usr/src/ -R
(natty-i386)root@serverman:/home/supermario# apt-get install linux-image-generic linux-headers-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  dmsetup grub-common grub-gfxpayload-lists grub-pc libdevmapper1.02.1 libfreetype6 libfuse2 linux-firmware linux-headers-2.6.38-8
  linux-headers-2.6.38-8-generic linux-image-2.6.38-8-generic os-prober ucf wireless-crda
Suggested packages:
  multiboot-doc grub-emu xorriso desktop-base fuse-utils fdutils linux-doc-2.6.38 linux-source-2.6.38 linux-tools
The following NEW packages will be installed:
  dmsetup grub-common grub-gfxpayload-lists grub-pc libdevmapper1.02.1 libfreetype6 libfuse2 linux-firmware linux-headers-2.6.38-8
  linux-headers-2.6.38-8-generic linux-headers-generic linux-image-2.6.38-8-generic linux-image-generic os-prober ucf wireless-crda
0 upgraded, 16 newly installed, 0 to remove and 0 not upgraded.
Need to get 68.5 MB of archives.
After this operation, 253 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://archive.ubuntu.com/ubuntu/ natty/main libfreetype6 i386 2.4.4-1ubuntu2 [314 kB]
Get:2 http://archive.ubuntu.com/ubuntu/ natty/main wireless-crda i386 1.13 [14.9 kB]
Get:3 http://archive.ubuntu.com/ubuntu/ natty/main linux-image-2.6.38-8-generic i386 2.6.38-8.42 [35.8 MB]
Get:4 http://archive.ubuntu.com/ubuntu/ natty/main libdevmapper1.02.1 i386 2:1.02.48-4ubuntu2 [62.2 kB]
Get:5 http://archive.ubuntu.com/ubuntu/ natty/main dmsetup i386 2:1.02.48-4ubuntu2 [37.9 kB]
Get:6 http://archive.ubuntu.com/ubuntu/ natty/main ucf all 3.0025+nmu1ubuntu1 [54.3 kB]
Get:7 http://archive.ubuntu.com/ubuntu/ natty/main libfuse2 i386 2.8.4-1.1ubuntu4 [102 kB]
Get:8 http://archive.ubuntu.com/ubuntu/ natty/main grub-common i386 1.99~rc1-13ubuntu3 [1973 kB]
Get:9 http://archive.ubuntu.com/ubuntu/ natty/main grub-pc i386 1.99~rc1-13ubuntu3 [923 kB]
Get:10 http://archive.ubuntu.com/ubuntu/ natty/main grub-gfxpayload-lists i386 0.2 [2956 B]
Get:11 http://archive.ubuntu.com/ubuntu/ natty/main linux-firmware all 1.52 [17.5 MB]
Get:12 http://archive.ubuntu.com/ubuntu/ natty/main linux-headers-2.6.38-8 all 2.6.38-8.42 [10.9 MB]
Get:13 http://archive.ubuntu.com/ubuntu/ natty/main linux-headers-2.6.38-8-generic i386 2.6.38-8.42 [800 kB]
Get:14 http://archive.ubuntu.com/ubuntu/ natty/main linux-headers-generic i386 2.6...

[Alex Chiang (achiang)]

Hi Mario,

I can't seem to reproduce this either, but many things have changed in my environment.

In any case, I'll just close this out for now.

Thanks.