Re: The same symbol pulled in from libc_pic.a and dl-allobjs.os?

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Tue, Jun 28, 2011 at 3:00 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> Team,
>
> One of my automated builders recently failed to build glibc git trunk
> for hppa-linux with the following failure:
> ~~~
> gcc ? -nostdlib -nostartfiles -r -o
> /home/carlos/fsrc/glibc-work/builds/glibc/elf/librtld.map.o '-Wl,-('
> /home/carlos/fsrc/glibc-work/builds/glibc/elf/dl-allobjs.os
> /home/carlos/fsrc/glibc-work/builds/glibc/libc_pic.a -lgcc '-Wl,-)'
> -Wl,-Map,/home/carlos/fsrc/glibc-work/builds/glibc/elf/librtld.mapT
> /home/carlos/fsrc/glibc-work/builds/glibc/libc_pic.a(dl-addr.os): In
> function `_dl_addr_inside_object':
> /home/carlos/fsrc/glibc-work/src/glibc/elf/dl-addr.c:157: multiple
> definition of `_dl_addr_inside_object'
> /home/carlos/fsrc/glibc-work/builds/glibc/elf/dl-allobjs.os:/home/carlos/fsrc/glibc-work/src/glibc/elf/dl-open.c:672:
> first defined here
> /home/carlos/fsrc/glibc-work/builds/glibc/libc_pic.a(_itoa.os): In
> function `_itoa':
> /home/carlos/fsrc/glibc-work/src/glibc/stdio-common/_itoa.c:215:
> multiple definition of `_itoa'
> /home/carlos/fsrc/glibc-work/builds/glibc/elf/dl-allobjs.os:/home/carlos/fsrc/glibc-work/src/glibc/elf/dl-minimal.c:300:
> first defined here
> /home/carlos/fsrc/glibc-work/builds/glibc/libc_pic.a(init-first.os):(.data+0x0):
> multiple definition of `__libc_multiple_libcs'
> /home/carlos/fsrc/glibc-work/builds/glibc/elf/dl-allobjs.os:(.bss+0x7c):
> first defined here
> collect2: ld returned 1 exit status
> ~~~
>
> Has anyone else seen this?
>
> I'd hate to spend an evening debugging this to find out it was a known issue.

In an effort to stub out the STT_GNU_IFUNC support I had added a call
to __libc_fatal in dl-irel.h, unfortunately on hppa __libc_fatal will
pull in the generic stack backtracing code which in turn eventually
pulls in dl-addr.os and several other pieces.

This is effectively an untested configuration and the way the object
files are arranged to be linked can't support this, that is to say
that there are conflicting symbols, and the fix is to avoid the
situation happening in the first place.

Removing the calls to __libc_fatal in the early loader fixes this
issue. I think I need to rely on _dl_debug_printf and an ABORT_INSN to
do what I want.

Cheers,
Carlos.