Symbol redefinition building 2.6.6 UML kernel

["Kevin P. Fleming" <kpfleming at linuxfromscratch dot org>]

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 :-)