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]

Re: crosscompiler x86->solaris2.8


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]