crossgcc building problem

Sun May 5 14:57:00 GMT 2002

miki.shapiro@eAladdin.com wrote:
> 
> Okay, seems like everything's in place:
> binutils-2.11.2
> gcc-3.0.4
> Solaris  7's libs and includes
> gdb-5.1.1
> 
> I ran into two more things I can't quite figure out:
> 1. Hello World compilation:
> program hw.cpp:
> 
> #include <stdio.h>
> main (int argc, char** argv)
> {
>         printf ("Hello World!\n");
>         return 0;
> }
> 
> Compiled with native compiler and dynamically linked (gcc hw.cpp):
> #file a.out
> a.out:          ELF 32-bit MSB executable SPARC Version 1, dynamically
> linked, not stripped
> sized 5853 bytes.

 I got about 6300 bytes (on disk) with my g++-3.0.4 for Solaris7 on Linux/x86
host with your test program...

> And finally, compiled with cross-compiler and dynamically linked:
> (using cd $xcompiler/bin; ./gcc hw.cpp ../lib/libstdc++.so.2.10.0)

 What does the 'libstdc++.so.2.10.0' do here, g++-3.0.4 uses one with the
name 'libstdc++.so.3', symlinked to 'libstdc++.so.3.0.4'...

> #file a.out
> a.out:          ELF 32-bit MSB executable SPARC Version 1, dynamically
> linked, not stripped
> and for some weird reason, sized 369284 bytes. WHY SO BIG?

 Hard to say when something really unsane seems to have happened...

> Here's ldd on this binary:
> 14:55|[May]
> mikisu:/usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/bin#ldd -r
> a.out
>         libstdc++.so.2.10.0 =>   /usr/local/lib/libstdc++.so.2.10.0
>         libm.so.1 =>     /usr/lib/libm.so.1
>         libc.so.1 =>     /usr/lib/libc.so.1
>         libdl.so.1 =>    /usr/lib/libdl.so.1
>         /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1

 In any case a g++-3.0.4 produced executable shouldn't use the g++-2.95.x -
level 'libstdc++.so.2.10.0'. My g++-3.0.4-produced executable shows with
'objdump -p' :

--------------------------- clip ----------------------------------------
hi_sol2_7.x:     file format elf32-sparc

Program Header:
    PHDR off    0x00000034 vaddr 0x00010034 paddr 0x00010034 align 2**2
         filesz 0x000000a0 memsz 0x000000a0 flags r-x
  INTERP off    0x000000d4 vaddr 0x000100d4 paddr 0x000100d4 align 2**0
         filesz 0x00000011 memsz 0x00000011 flags r--
    LOAD off    0x00000000 vaddr 0x00010000 paddr 0x00010000 align 2**16
         filesz 0x00000800 memsz 0x00000800 flags r-x
    LOAD off    0x00000800 vaddr 0x00020800 paddr 0x00020800 align 2**16
         filesz 0x00000190 memsz 0x000001b0 flags rwx
 DYNAMIC off    0x000008d8 vaddr 0x000208d8 paddr 0x000208d8 align 2**2
         filesz 0x000000b8 memsz 0x000000b8 flags rw-

Dynamic Section:
  NEEDED      libstdc++.so.3
  NEEDED      libm.so.1
  NEEDED      libgcc_s.so.1
  NEEDED      libc.so.1
  INIT        0x10558
  FINI        0x107d4
  HASH        0x100e8
  STRTAB      0x10300
  SYMTAB      0x10190
  STRSZ       0x151
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x20824
  PLTRELSZ    0x60
  PLTREL      0x7
  JMPREL      0x104f8
  RELA        0x104d4
  RELASZ      0x84
  RELAENT     0xc
  VERNEED     0x10494
  VERNEEDNUM  0x2
  VERSYM      0x10466

Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 03 GCC_3.0
  required from libc.so.1:
    0x0537ccb3 0x00 02 SYSVABI_1.3
--------------------------- clip ----------------------------------------

 I didn't have a Solaris7-machine for 'ldd' available just now...

 Anyway at runtime the produced executable should look for 'libstdc++.so.3' and the
usual C-runtime libraries 'libc.so.1', 'libm.so.1' and 'libgcc_s.so.1' somewhere...

> Where I come to funny thing #2 - it's using
> /usr/local/lib/libstdc++.so.2.10.0 instead of
> /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/lib/libstdc++.so.2.10.0

 It searches via the normal paths for shared libs, unless told otherwise with the
ld-option '-rpath <dirname>' at link-time:

--------------------------- clip ----------------------------------------
  --retain-symbols-file FILE  Keep only symbols listed in FILE
  -rpath PATH                 Set runtime shared library search path
  -rpath-link PATH            Set link time shared library search path
  -shared, -Bshareable        Create a shared library
--------------------------- clip ----------------------------------------

> I don't think I want that to happen. Does that mean I did something wrong
> when configuring/building the linker(or compiler)?
> If so, what, or how can I figure out what?

 Where is your new 'libstdc++.so.3.0.4' ?  The GCC-install might put it somewhere
else, but the library :

 /usr/local/cpl/sparc-sun-solaris2.7/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4/libstdc++.so

should be a symlink to it. And this should always be the first 'libstdc++.so' found.
Now it seems like something else was found first at link-time.

 Could it be that you copied the gcc-2.95.x-version of 'libstdc++.so' with the other
'Solaris2.7' libraries?  How on earth you got the :
 /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/lib/libstdc++.so.2.10.0
when the gcc-3.0.4-build doesn't produce this ?  Did you force the symlink to point
to this instead of the right 'libstdc++.so.3.0.4' ?

 Using the '-Wl,-verbose' in the GCC-command line enables one to see what happens at
link-time, which libraries will be tried and which ones will be found and used...

Cheers, Kai

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com