This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


"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


objdump...

SYMBOL TABLE:
...snip...
REG_G7           g     R *UND*  0000000000000000 __thread_self
0000000000000000         *UND*  0000000000000000 _GLOBAL_OFFSET_TABLE_
REG_G2           g     R *UND*  0000000000000000 #scratch
0000000000000000         *UND*  0000000000000000 _DYNAMIC
REG_G3           g     R *UND*  0000000000000000 #scratch
REG_G6           g     R *UND*  0000000000000000 #scratch
0000000000000000         *UND*  0000000000000000 _dl_lookup_symbol_x
0000000000000000         *UND*  0000000000000000 _dl_verbose
0000000000000000         *UND*  0000000000000000 _dl_argv
0000000000000000         *UND*  0000000000000000 _dl_dprintf
0000000000000000         *UND*  0000000000000000 memcpy
...snip...

00000000000004a0 <elf_machine_load_address.3>:
     4a0:       9d e3 bf 30     save  %sp, -208, %sp
     4a4:       ca 77 a7 e7     stx  %g5, [ %fp + 0x7e7 ]
     4a8:       2f 00 00 00     sethi  %hi(0), %l7
                        4a8: R_SPARC_HI22       _GLOBAL_OFFSET_TABLE_+0xfffffffffffffffc
     4ac:       40 00 00 04     call  4bc <elf_machine_load_address.3+0x1c>
     4b0:       ae 05 e0 00     add  %l7, 0, %l7        ! 0 <elf_machine_matches_host.1-0x460>
                        4b0: R_SPARC_LO10       _GLOBAL_OFFSET_TABLE_+0x4
     4b4:       40 00 00 00     call  4b4 <elf_machine_load_address.3+0x14>
                        4b4: R_SPARC_WDISP30    _DYNAMIC
     4b8:       40 00 00 00     call  4b8 <elf_machine_load_address.3+0x18>
                        4b8: R_SPARC_WDISP30    _GLOBAL_OFFSET_TABLE_
     4bc:       ae 05 c0 0f     add  %l7, %o7, %l7
     4c0:       c2 5d c0 00     ldx  [ %l7 ], %g1
     4c4:       ae 25 c0 01     sub  %l7, %g1, %l7
     4c8:       c2 03 e0 08     ld  [ %o7 + 8 ], %g1
     4cc:       c4 03 e0 0c     ld  [ %o7 + 0xc ], %g2
     4d0:       82 20 40 02     sub  %g1, %g2, %g1
     4d4:       83 28 60 02     sll  %g1, 2, %g1
     4d8:       83 38 60 00     sra  %g1, 0, %g1
     4dc:       ae 05 c0 01     add  %l7, %g1, %l7
     4e0:       81 c7 e0 08     ret
     4e4:       91 ed ff fc     restore  %l7, -4, %o0



> 
> Martin
> 
> >
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]