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] |
Joel Sherrill wrote: > > Kai Ruottu wrote: > > Neither has 'solaris2.8', there are subdirs for 'solaris2.5' > > - 'solaris2.7', but not for 'solaris2.8' in 'libstdc++-v3/config/os/solaris'. > > So it is not 'supported' yet in 'gcc-3.0.4'... > > Thanks Kai. But libstdc++-v3/configure.target lists solaris 2.7 and > solaris 2.8 as supposed to use the 2.7 subdirectory in my 3.0.4 source > and 3.1 CVS checkout. So not matching native or cross doesn't make > sense. Thanks to you too for correcting this... Seeing what stuff from where was symlinked into the : foo/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits/ would tell if the right stuff from 'libstdc++-v3/config/os/solaris/solaris2.7' is now there... If not, something weird happened. > Another problem... I am using my local Linux x86->Solaris toolset to > canadian cross build embedded cross toolsets for Solaris hosts. I can > build > binutils successfully but gcc is another matter. My build for > powerpc-rtems > fails like this: > > sparc-solaris-gcc -g -O2 -o makeinfo makeinfo.o multi.o > ../lib/libtxi.a > /opt/solaris/lib/gcc-lib/sparc-solaris/3.0.4/../../../../sparc-solaris/lib/libc. > a(nss_deffinder.o): In function `SO_per_src_lookup': > nss_deffinder.o(.text+0x88): undefined reference to `_dlopen' > nss_deffinder.o(.text+0xb8): undefined reference to `_dlsym' > nss_deffinder.o(.text+0xcc): undefined reference to `_dlclose' > /opt/solaris/lib/gcc-lib/sparc-solaris/3.0.4/../../../../sparc-solaris/lib/libc. > a(nss_deffinder.o): In function `SO_per_src_delete': > nss_deffinder.o(.text+0x104): undefined reference to `_dlclose' > > Any thoughts on what is going wrong? It is obviously something to do > with > dynamic linking. Even if add -static, I can't get rid of these. Hints > appreciated. Older GNU ld's couldn't find the 'NEEDED' stuff mentioned in the '.so' files: ------------------- clip ---------------------------------- H:\usr\local\sparc-solaris2.7\lib>..\bin\objdump -p libc.so libc.so: file format elf32-sparc Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16 filesz 0x000a2110 memsz 0x000a2110 flags r-x LOAD off 0x000a2110 vaddr 0x000b2110 paddr 0x00000000 align 2**16 filesz 0x000062b4 memsz 0x00007c08 flags rwx DYNAMIC off 0x000a452c vaddr 0x000b452c paddr 0x00000000 align 2**0 filesz 0x000000c0 memsz 0x00000000 flags rwx Dynamic Section: NEEDED libdl.so.1 <------------ INIT 0x969f0 FINI 0x96a30 SONAME libc.so.1 AUXILIARY /usr/platform/$PLATFORM/lib/libc_psr.so.1 VERDEF 0x17658 ------------------- clip ---------------------------------- or something, this happens with the Mingw-host even now... Anyway the '_dl*'-stuff is there in 'libdl.so.1' and it is not mentioned in the command line given to 'ld', but 'ld' must search it because it is told as 'NEEDED' in 'libc.so'... Here are the symbols in 'libdl.so.1' : ------------------- clip ---------------------------------- H:\usr\local\sparc-solaris2.7\lib>..\bin\nm -p libdl.so.1 00000000 ? _START_ 00000864 t _dlmap 000008b8 b _END_ 000008ac t bind_guard 00000864 t dlmap 000008b4 b dbg_mask 00000000 V SUNW_0.7 00000000 A SUNW_0.8 000008b8 B _end 00000884 W dlclose 00000874 T _dlopen <------- 0000086c T _dlmopen 00000000 A SUNWprivate_1.1 0000085c T _dlinfo 00000894 T _dladdr 00000468 ? _DYNAMIC 0000088c T _dlerror 000008a4 T _ld_concurrency 0000089c W dldump 00000884 T _dlclose <------- 00000000 A SISCD_2.3 00000000 A SUNW_1.1 00000000 A SUNW_1.2 00000000 A SUNW_1.3 0000087c W dlsym 00000000 A _edata 00000000 A _PROCEDURE_LINKAGE_TABLE_ 00000874 W dlopen 0000086c W dlmopen 000008b4 B _etext 00000894 W dladdr 0000089c T _dldump 0000088c W dlerror 0000085c W dlinfo 0000087c T _dlsym <-------- ------------------- clip ---------------------------------- The NEEDED-stuff has been sometimes called as 'linked' stuff, but 'chained' could be better... "Linked stuff gets not linked, what is the problem?", for this case doesn't sound good ;-) Here was the principle... Using a '-Wl,-verbose' in the GCC-command line, redirecting the output to a logfile and seeing it will tell what then happens during linking... There should be a notice about 'libc.so' needing the 'libdl.so.1' and then linking against it... If this doesn't happen automatically, putting the 'libdl.so.1' somewhere in the LINK_SPEC in 'specs', or updating the target binutils can be a solution... Oops, also adding a '-rpath-link <libdir>' to tell where the dynamic libs are at link-time, after telling the name with the '-dynamic-linker /usr/lib/libdl.so.1', may help : ------------------- clip ---------------------------------- *link: -m elf32_sparc %{h*} %{v:-V} %{b} %{Wl,*:%*} %{static:-dn -Bstatic} \ %{!static:--dynamic-linker /usr/lib/ld.so.1 \ -rpath-link /usr/local/sparc-solaris2.7/lib} \ ------------------- clip ---------------------------------- I don't remember when using the '-rpath-link' became unnecessary, but binutils-2.10.x may still need it for the NEEDED stuff. 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] |