This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |