Compilation problem when downgrading from 64-bit gcc to 32-bit gcc
 

Hi all,
I just checked out a fresh Linux kernel 2.6.30 source code from kernel.org. If I leave everything intact and just do a "make all", it compiled successfully. I saw that it uses standard gcc, ld, ar, nm ... from /usr/bin to compile. Since it's compiled natively on an x86_64 machine (Red Hat), I assume it's 64-bit toolchains. Here is the info I got:
/usr/bin/gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9)
Copyright (C) 2006 Free Software Foundation, Inc.

Due to some incompatibility issue, I have to compile this source code in 32-bit. I forced the SUBARCH := i386 in the Makefile then I used the toolchains provided in-house called gcc.c4.2.1-p0.linux, ld.c4.2.1-p0.linux, nm.c4.2.1-p0.linux ... to compile. However, I got these following error:
...
CC lib/reciprocal_div.o
CC lib/rwsem.o
CC lib/sha1.o
CC lib/show_mem.o
CC lib/string.o
CC lib/vsprintf.o
AR lib/lib.a
CC arch/x86/lib/msr-on-cpu.o
LD arch/x86/lib/built-in.o
CC arch/x86/lib/delay.o
AS arch/x86/lib/getuser.o
CC arch/x86/lib/memcpy_32.o
AS arch/x86/lib/putuser.o
CC arch/x86/lib/string_32.o
CC arch/x86/lib/strstr_32.o
CC arch/x86/lib/usercopy_32.o
AR arch/x86/lib/lib.a
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.cpuinit.data+0x0): Section mismatch in reference from the variable initial_code to the function .init.text:i386_start_kernel() The variable __cpuinitdata initial_code references a function __init i386_start_kernel().
If i386_start_kernel is only used by initial_code then annotate i386_start_kernel with a matching annotation.

GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `next_device':
core.c:(.text+0x9367d): undefined reference to `klist_next'
drivers/built-in.o: In function `device_find_child':
(.text+0x936aa): undefined reference to `klist_iter_init'
drivers/built-in.o: In function `device_find_child':
(.text+0x936d7): undefined reference to `klist_iter_exit'
drivers/built-in.o: In function `device_for_each_child':
(.text+0x93701): undefined reference to `klist_iter_init'
drivers/built-in.o: In function `device_for_each_child':
...

Here is everything I changed from the original Makefile:
TOOLS_VER=c4.2.1-p0.linux
SUBARCH := i386

HOSTCC = gcc.$(TOOLS_VER)
HOSTCXX = g++.$(TOOLS_VER)
HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
HOSTCXXFLAGS = -O2

CC = gcc.$(TOOLS_VER)
AS = $(CC)
LD = $(CC) -nostdlib
CPP = $(CC) -E
AR = ar.$(TOOLS_VER)
NM = nm.$(TOOLS_VER)
STRIP = strip.$(TOOLS_VER)
OBJCOPY = objcopy.$(TOOLS_VER)
OBJDUMP = objdump.$(TOOLS_VER)

Does anyone knows what's wrong and how to fix it? Any help is greatly appreciated.

Thanks,

to compile 32bit code you need GCC with multilib capabilities and all the 32bit dev's somewhere. My best advice for making it would be a chroot, that would be the easiest method I would think. Why are you wanting a 32bit kernel when you are running a 64bit system? Even if you get it compiled it won't boot the system.

mushroomboy is onto something.

The other day, I attempted to build a kernel for my 386/32 firewall machine, but I did it on my 64bit -current machine.

I did it by:

which all worked fine so far; and then I bzipped the resulting build, copied it all over to the firewall machine, extracted it, and tried to run "make modules_install" on the 32bit machine, and it wouldn't work; it gave me some errors I can't remember, and I couldn't get it to work. I ended up rebuilding the thing from scratch on the firewall machine (slow).

There's surely a way to do this (chroot??) but I dunno exactly what it is. :scratch:

Sasha

Well in Debian the 32bit chroot is easy...

http://www.debian-administration.org..._Debian_system

On other systems I don't know how to do it... Once you get the chroot set up as far as everything is concerned it IS a 32bit system, because everything is run in the chroot with all the 32bit libs and 32bit programs.

I'm pretty sure each distro has it's own way to do this, just google your distro with 32bit chroot or something.

[edit]

This also might work:
http://forums.whirlpool.net.au/forum...fm/738014.html

Just to clarify: I meant to mean "Is chroot a/the way?" as opposed to "What is chroot??" :)

Sasha

DEBOOTSTRAP!!! That's what it was:
http://blogs.koolwal.net/2009/06/04/...machine-amd64/

That's the same as a chroot!!!

Cool :) and kushalkoolwal is an LQ member I believe.

Thanks for that link, mushroom.
Sasha

I got it working already with the help of Kevin Dankwardt, my Linux instructor. It could be a bug in 2.6.31-rc2 source code that I'm using too but I'm not sure. It's due to this line at the end of file lib/klist.c

EXPORT_SYMBOL_GPL(klist_next);

For some reasons, klist_next symbol is available for linking when I compiled natively using 64-bit gcc, but when compiled using our homegrown toolchains gcc.c4.2.1-p0, linker couldn't find klist_next anymore. Maybe our tools are non-GPL and thus this symbol wasn't exported. after changing that line to:

EXPORT_SYMBOL(klist_next);

I was able to compile successfully. Thank you very much to whoever replied.

Best Regards,
huyhoang