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

["M.H.VanLeeuwen" <vanl at megsinet dot net>]

"H. J. Lu" wrote:
> 
> On Thu, May 06, 2004 at 07:30:18AM -0500, M.H.VanLeeuwen wrote:
> > "M.H.VanLeeuwen" wrote:
> > >
> > > Dan Kegel wrote:
> > > >
> > > > 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.
> > >
> > > Hi,
> > >
> > > I blasted all gcc_eh references from Makeconfig and still get the _DYNAMIC error from glibc CVS tree.
> > >
> > > make -C ../posix objdir=/cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-uname.os rtld-_exit.os
> > > rtld-getpid.os rtld-environ.os'
> > > /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/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]: *** [/cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/elf/sln] Error 1
> > >
> > > I'm trying Jakub's suggestion below; if I interpreted correctly,
> > > this is what was meant:
> > >
> > > --- ./sysdeps/sparc/sparc64/dl-machine.h.orig   Wed May  5 22:26:32 2004
> > > +++ ./sysdeps/sparc/sparc64/dl-machine.h        Wed May  5 22:32:26 2004
> > > @@ -67,6 +67,7 @@
> > >
> > >  /* Return the run-time load address of the shared object.  */
> > >  static inline Elf64_Addr
> > > +__attribute__((always_inline))
> > >  elf_machine_load_address (void)
> > >  {
> > >    register Elf32_Addr *pc __asm ("%o7");
> > >
> > > Will post results of build later.
> >
> > Same error:
> >
> > sparc64-unknown-linux-gnu-gcc  -nostdlib -nostartfiles -static -o /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/elf/sln
> > /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/csu/crt1.o
> > /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/csu/crti.o `sparc64-unknown-linux-gnu-gcc  --print-file-name=crtbegin.o`
> > /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/elf/sln.o  /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/libc.a
> > -lgcc /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/libc.a `sparc64-unknown-linux-gnu-gcc  --print-file-name=crtend.o`
> > /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/csu/crtn.o
> > /cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/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]: *** [/cross/crosstool-0.28-rc11/build/sparc64-unknown-linux-gnu/gcc-3.4.0-glibc-cvs/build-glibc/elf/sln] Error 1
> >
> >
> 
> It may be a compiler issue since it generates an unused inline function.
> I suggest you file a gcc bug report. Or you can this try kludge.
> 
> H.J.
> ---
> 2004-05-06  H.J. Lu  <hongjiu.lu@intel.com>
> 
>         * sysdeps/sparc/sparc64/dl-machine.h (elf_machine_load_address):
>         Define only if IS_IN_rtld is defined.
> 
> --- sysdeps/sparc/sparc64/dl-machine.h.rtld     2004-03-05 11:42:32.000000000 -0800
> +++ sysdeps/sparc/sparc64/dl-machine.h  2004-05-06 08:53:39.000000000 -0700
> @@ -65,6 +65,7 @@ elf_machine_dynamic (void)
>    return *elf_pic_register;
>  }
> 
> +#ifdef IS_IN_rtld
>  /* Return the run-time load address of the shared object.  */
>  static inline Elf64_Addr
>  elf_machine_load_address (void)
> @@ -85,6 +86,7 @@ elf_machine_load_address (void)
>       pc[3]*4 is l_addr + _GLOBAL_OFFSET_TABLE_ - (long)pc - 12  */
>    return (Elf64_Addr) got - *got + (Elf32_Sword) ((pc[2] - pc[3]) * 4) - 4;
>  }
> +#endif
> 
>  /* We have 4 cases to handle.  And we code different code sequences
>     for each one.  I love V9 code models...  */


Yes, this patch does indeed seem to work, at least there is no "elf_machine_load_address.3" in dl-reloc.o anymore while
dl-reloc.os still does have "elf_machine_load_address.3".  Also, libc.a has no references to _DYNAMIC.  I'm starting a
complete rebuild binutils-cvs, gcc-3.4.0, and glibc-cvs with most recent CVS updates and this patch.

Thanks,
Martin