From: Jeremy Utley <jerutley@gm...> - 2004-07-22 00:51:33
Got a compiliation problem with UML kernels, looking to perhaps get
some input from you. Background:
I'm a book editor and tester for the LinuxFromScratch project, as well
as a hobbyist UML user. Recently, tho, I started having problems
compiling UML kernels. We've traced the problems down to what appears
to be a linker problem, but the strange part is, it doesn't appear to
affect everyone, even some with an almost identical system to my own.
Here's the text of a message that was recently posted to the binutils
I'm trying to help some members of the LFS team debug a problem
building a 2.6.6-based UML kernel. At this time, we cannot determine
whether the problem is actually the fault of "ld" or if we have a
toolchain build quality problem. The testing has been done with FSF
2.15 binutils and HJL 184.108.40.206.1 binutils.
Here is the scenario:
- unpack a linux-2.6.6 kernel tarball
- apply the 2.6.6 UML kernel patch (from
- run "make ARCH=um menuconfig" and turn off UML Networking Multicast support
- run "make ARCH=um linux"
On some of our systems, during the final link of vmlinux, there are
symbol redefinitions of the common functions from glibc that are also
present in the kernel. Primarily this includes the string functions,
but there are others.
I have followed this down to the object file "unmap_fin.o" (from
arch/um/kernel/tt) that is built; this object file is made by linking
"unmap.o" with the system's libc (glibc-CVS in our case) but producing
a relocatable object. This relocatable object is then linked into
vmlinux using the linker script at arch/um/uml.lds.S, which appears to
just "force" the contents of this file into the resulting kernel image
as raw data.
As best I can tell, during this final link step the linker should not
be paying attention to any exported symbols from this object file, but
it does. When it works properly, the symbol redefinitions do not occur
and the final link proceeds to completion.
We are concerned that we may be providing faulty toolchain build
instructions to our users, although we have not had problems building
hundreds of other packages. In fact, these same build instructions
work fine for the UML kernel on some of our testers' systems, just not
all of them.
Can anyone provide some assistance to us to try to isolate this
problem? Thanks in advance :-)
Since this does also involve UML, I thought I would transcribe the
information here, to see if we can get any input. For your reference,
the toolchain on the host systems experiencing the problem consist of
Binutils 220.127.116.11.1 (HJ Lu's branch releases)
Glibc CVS code from roughly July 2, 2004
I'm happy to provide any and all information requested in trying to
diagnose this problem.
Editor, LinuxFromScratch project