This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Symbol redefinition building 2.6.6 UML kernel
- From: "Kevin P. Fleming" <kpfleming at linuxfromscratch dot org>
- To: binutils at sources dot redhat dot com
- Cc: jeremy at jutley dot org
- Date: Wed, 21 Jul 2004 16:18:40 -0700
- Subject: Symbol redefinition building 2.6.6 UML kernel
- Organization: Linux From Scratch
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 2.15.90.0.1 binutils.
Here is the scenario:
- unpack a linux-2.6.6 kernel tarball
- apply the 2.6.6 UML kernel patch (from
http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.6.6-1.bz2)
- 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 :-)