This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Symbol redefinition building 2.6.6 UML kernel
- From: "H. J. Lu" <hjl at lucon dot org>
- To: "Kevin P. Fleming" <kpfleming at linuxfromscratch dot org>
- Cc: binutils at sources dot redhat dot com, jeremy at jutley dot org
- Date: Wed, 21 Jul 2004 17:35:51 -0700
- Subject: Re: Symbol redefinition building 2.6.6 UML kernel
- References: <40FEF9D0.7030002@linuxfromscratch.org>
On Wed, Jul 21, 2004 at 04:18:40PM -0700, Kevin P. Fleming wrote:
> 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 :-)
Please open a bug report at
http://sources.redhat.com/bugzilla/
and provide a pointer to a complete testcase. If you can show me how to
reproduce it, I will look into it.
H.J.