Re: Current binutils failed to build glibc

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, Sep 30, 2004 at 11:13:15PM -0700, Roland McGrath wrote:
> > With the current binutils, glibc failed to build
> > 
> > gcc   -nostdlib -nostartfiles -r -o
> > /export/build/gnu/glibc-nptl-3.4/build-i686-linux/elf/librtld.map.o
> > '-Wl,-('
> > /export/build/gnu/glibc-nptl-3.4/build-i686-linux/elf/dl-allobjs.os
> > /export/build/gnu/glibc-nptl-3.4/build-i686-linux/libc_pic.a -lgcc
> > '-Wl,-)'
> > -Wl,-Map,/export/build/gnu/glibc-nptl-3.4/build-i686-linux/elf/librtld.mapT
> > /usr/local/bin/ld: errno: TLS definition in
> > /export/build/gnu/glibc-nptl-3.4/build-i686-linux/libc_pic.a(errno.os)
> > section .tbss mismatches non-TLS reference in
> > /export/build/gnu/glibc-nptl-3.4/build-i686-linux/elf/dl-allobjs.os
> > /export/build/gnu/glibc-nptl-3.4/build-i686-linux/libc_pic.a: could not
> > read symbols: Bad value
> > 
> > Although I believe it is a glibc build bug, I was wondering if the
> > binutils should tolerate this misuse.

I wondered at the time I okayed your patch whether you were being a
little too strict..

> It certainly should not.  Resolving TLS and non-TLS symbols together would
> be disastrous at runtime, and refusing at link time to let it happen is the
> right thing.

I'm not so sure.  The situation that HJ is talking about is an undefined
reference in one file, where the symbol type is not specified, being
satisfied by a tls symbol from another file.  It's not a case of a tls
symbol being used in both tls and non-tls relocations.

I suppose the real bug is that the assembler doesn't automatically give
an undefined symbol a tls type if it is used by a tls reloc.  For
example, see the ld-powerpc/ changes I checked in to satisfy HJ's strict
checking.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre