Re: How to make a portable toolchain?

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Bin Zhou wrote:
> 
> I can link to libc statically on Solaris8 with link option "-Wl,-static".

 How I then have expected the normal '-static' being used there too ?
 
> As static libc requires libdl on Solaris, so I put -ldl in the LDFLAGS,
> but I got linkage error saying "can not find -ldl".

 Are you sure the 'libdl.a' will be needed and is not only a bug in your
current 'specs' ?

 I had this bug in my Mingw-hosted toolset and after removing it by wrapping
the '-ldl' to be a '%{!static:-ldl}' instead, all the simple '-static' tests
linked ok, like:
 
H:\usr\local\samples>gcc-sparc-solaris7 -static -Os -o tst_sol2-s.x tprintf.c

H:\usr\local\samples>..\sparc-solaris2.7\bin\objdump -p tst_sol2-s.x

tst_sol2-s.x:     file format elf32-sparc

Program Header:
    LOAD off    0x00000000 vaddr 0x00010000 paddr 0x00010000 align 2**16
         filesz 0x0002b672 memsz 0x0002b672 flags r-x
    LOAD off    0x0002b678 vaddr 0x0004b678 paddr 0x0004b678 align 2**16
         filesz 0x00001abc memsz 0x000026c8 flags rw-

 The bug I had inserted myself as an workaround for the bug in the Mingw-hosted
'ld', where the '-rpath-link' doesn't work (a Cygwin-hosted 'ld' works...).
Forcing to link against the 'libdl.so' after 'libc.so' was needed there. Under
Linux my 'lib-spec' in 'specs' is the normal:

-------------------------------------- clip -----------------------------------
*endfile:
crtend.o%s crtn.o%s

*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}
%{shared:-G -dy %{!mimpure-text:-z text}} %{symbolic:-Bsymbolic -G -dy -z text}
%{G:-G} %{YP,*} %{R*} %{compat-bsd: %{!YP,*:%{p:-Y P,/usr/local/sparc-solaris2.7/ucblib}
%{pg:-Y P,/usr/local/sparc-solaris2.7/ucblib}
%{!p:%{!pg:-Y P,/usr/local/sparc-solaris2.7/ucblib}}}
-R /usr/local/sparc-solaris2.7/ucblib} %{Qy:} %{!Qn:-Qy}

*lib:
%{compat-bsd:-lucb -lsocket -lnsl -lelf -laio} %{!shared: %{!symbolic: %{pthreads:-lpthread} %{!pthreads:%{threads:-lthread}}
-lc}}

-------------------------------------- clip -----------------------------------

No '-ldl' after the '-lc' needed, the '-rpath-link' in the 'link-spec' does the
necessary magic and the 'libdl.so' will be found... Fixing the 'specs' is quite
normal with all Linux, Solaris2, SVR4, FreeBSD etc. targets which use shared
libs.

 Perhaps you have added the '-ldl' bug there yourself and now blame the FSF-people
doing this ;-)

 I wouldn't expect Solaris2.8 being that much different from Solaris2.7, which
I have as the target, so the previous things for 2.7 can be applied for 2.8. Of
course one must use one's own $prefix in the paths, not my '/usr/local' (the
default $prefix).

 BTW, the only GCC which I have compiled for Solaris2.7-host, seemed to work ok
also under Solaris2.6, when linked against the Solaris2.7 shared libs. So the
situation is not that bad with the 'commercial' Unix'es as it perhaps is with
the Linux'es...

 I got the Sparc and x86 Solaris2.7 install CDs totally free from Sun, perhaps
they still deliver the kit, so not using 2.8 libs but 2.7 libs could offer better
compatability, all systems try to be 'backwards compatible', ie. '2.6' binaries
should work under '2.7' and '2.8' but normally the things don't work vice versa,
ie. that '2.8' binaries could work under '2.6' and '2.7'... Whether Sun gives its
2.5 and 2.6 libs free for the developers is unclear, but not after asking it from
Sun... Intel/RedHat seems to have used the Solaris v2.5 libs (and the glibc-2.1
for Linux) in their XScale-distribution:

-------------------------------------- clip -----------------------------------
Fri Jul  6 17:46:11 EDT 2001

GNUpro tools for the Intel X-Scale Microarchitecture are now hosted by Intel.

	http://developer.intel.com/design/intelxscale/dev_tools/

<snip>

GNUpro for x86 Red Hat Linux v6.1 hosts - ELF

	ftp://download.intel.com/design/intelxscale/dev_tools/i686-pc-linux-gnulibc2.1-x-xscale-elf.tar.Z
	http://developer.intel.com/design/intelxscale/dev_tools/i686-pc-linux-gnulibc2.1-x-xscale-elf.tar.Z

<snip>

GNUpro for SPARC SUN Solaris v2.5 hosts - ELF

	ftp://download.intel.com/design/intelxscale/dev_tools/sparc-sun-solaris2.5-x-xscale-elf.tar.Z
	http://developer.intel.com/design/intelxscale/dev_tools/sparc-sun-solaris2.5-x-xscale-elf.tar.Z
-------------------------------------- clip -----------------------------------

 Mimicking the 'big guys' is one of the reasons for me using glibc-2.1.3 as the
'production libc for Linux/x86' now, so that the linked executables could run
under all the recent Linux/x86's since the RedHat 6.2 age... Perhaps glibc-2.0.7
could be still better...

 Linking the GCC statically didn't came into my mind, just try to guess why...

H:\usr\local\samples>..\sparc-solaris2.7\bin\size tst_sol2-*.x
   text    data     bss     dec     hex filename
   5531     328     360    6219    184b tst_sol2-d.x
 177656    6837    3072  187565   2dcad tst_sol2-s.x

 So my advice would be to get some older Solaris2 libraries and then use them
when producing stuff for the used version and the newer ones after that and to
trust to the "backwards compatability" in Solaris2... Here is the 'objdump -p'
from the Solaris2.7 hosted 'cc1' for a cross-compiler, which run also under
Solaris2.6 :

-------------------------------------- clip -----------------------------------
cc1:     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 0x001edef2 memsz 0x001edef2 flags r-x
    LOAD off    0x001edef8 vaddr 0x0020def8 paddr 0x0020def8 align 2**16
         filesz 0x00006068 memsz 0x0001d908 flags rwx
 DYNAMIC off    0x001f3ec0 vaddr 0x00213ec0 paddr 0x00213ec0 align 2**2
         filesz 0x000000a0 memsz 0x000000a0 flags rw-

Dynamic Section:
  NEEDED      libc.so.1
  INIT        0x10f4c
  FINI        0x1c21d4
  HASH        0x100e8
  STRTAB      0x10850
  SYMTAB      0x10340
  STRSZ       0x280
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x213b54
  PLTRELSZ    0x318
  PLTREL      0x7
  JMPREL      0x10c34
  RELA        0x10bec
  RELASZ      0x360
  RELAENT     0xc
  VERNEED     0x10b9c
  VERNEEDNUM  0x1
  VERSYM      0x10af8

Version References:
  required from libc.so.1:
    0x0a3d2897 0x00 05 SUNW_0.7
    0x077a74f3 0x00 04 SISCD_2.3
    0x0a3d2899 0x00 03 SUNW_0.9
    0x0537ccb3 0x00 02 SYSVABI_1.3
-------------------------------------- clip -----------------------------------

 I don't know what those "Version References" require from the opsys version
(ie. from the runtime 'libc.so.1'), can anyone else interpret these?

 Which 'glibc' (or perhaps even the frozen 'libc5' ?) could be suitable for
the Linux/x86-hosted stuff in binary format is then another issue... It shouldn't,
what could be the result if an executable built for 'Win32' wouldn't under Win9x,
NT, ME, 2k and XP ? A very good news for all the MS-haters and very bad news for
the virus-writers ?
 
> Under /usr/lib on Solaris8, I can only see libdl.so but not libdl.a, this is
> the reason of above linkage error. --- SUN does not ship libdl.a

 What routines would be needed from the 'libdl.a' ?

 Please try to wrap the '-ldl' away for using with shared libs only and then
send us those undefined symbols-errors from the link (if any).
 
> If I configure cross gcc with option --disable-shared, can I get rid of
> option -ldl when I compile/link targets with the cross gcc?

 No, only fixing the bug in LIB_SPEC in the config files or just only in
the generated 'specs', editing the '*lib:' and '*link:' there...

 Ok, the Solaris2-host compatability problems are off-topic here, but the
Solaris2-related newsgroups, the 'Solaris2 Developer's Connection', the
Solaris2-FAQ (www.sunfreeware.com?) etc. could give more sane info...

Cheers, Kai


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