Re: trouble building glibc-2.3.2/gcc-3.4.0/sparc64 with cvs binutils

[Dan Kegel <dank at kegel dot com>]

H. J. Lu wrote:
> On Sun, May 02, 2004 at 09:54:03PM -0700, Dan Kegel wrote:
> > .../sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-2.3.2/build-glibc/libc.a(dl-reloc.o)(.text+0x4b4):
> > In function `elf_machine_load_address.3':
> > : undefined reference to `_DYNAMIC'
> > collect2: ld returned 1 exit status
> > make[2]: *** 
> > [.../sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-2.3.2/build-glibc/elf/sln] 
> > Error 1
>
> Can you try glibc from CVS? I couldn't find how it could wind up in
> dl-reloc.o.

I just did, and now it fails with

.../sparc64-unknown-linux-gnu/bin/ld: cannot find -lgcc_eh
collect2: ld returned 1 exit status
make[1]: *** [.../sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-20040501/build-glibc/libc.so] Error 1

Anyone know why the patch at the end of the thread
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html didn't go in?
I don't know how one bootstraps glibc if it requires -lgcc_eh.

Maybe I'll go back to glibc-2.3.2 and try to follow Jakub's hint:
> _DYNAMIC is only used in elf_machine_load_address, which is static inline
> function, but it is only used in rtld.c and nowhere else.
> So, certainly it should not be used in dl-reloc.o.
> If it does, it looks like a compiler problem.
> Try adding __attribute__((always_inline)) to it to see if it helps, but
> still I'd like to understand why elf_machine_load_address.3 is being emitted
> into assembly in dl-reloc.s at all.

- Dan

--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change