Re: gnu ld on sco5

[Kai Ruottu]

On Thu, 10 May 2001 16:45:44 GMT, <address@hidden> wrote:

>Currently `ld' from binutlis refuses to configure on sco5 since it is
>unable to convert COFF to ELF.  But even suchit still can be useful.

 For a cross-GCC to 'i386-sco3.2v5' the GNU ld is mostly the only
possibility.

>I may never with input / output coff.  All libraries I need are elf.
>There is small number of coff objects in `/usr/ccs/lib' (`crt*.o' and
>so), but I can convert them to elf using native tools (`cof2elf' or
>even just `ld -b elf -r'), put converted ones in another dir and
>modify / configure gcc (or other compiler) to use this object dir and
>gnu ld rather than `/usr/ccs/lib' and native ld.

 If not having the courage to edit the 'ld/configure.tgt', using
the command:

  ./configure --target=i386-sysv4.2 --enable-targets=i386-sco3.2

for the GNU ld, enables the SVR4-ELF and the SVR3.2-COFF support
in 'ld'. But those who have the courage, adding the 'unofficial'
SCO5-support happens in the 'ld/configure.tgt' by adding the same
things as in the previous 'configure' for the 'i386-sco3.2v5' :

--------------------- clip -------------------------------------
  i[3456]86-*-msdosdjgpp*) targ_emul=i386go32 ;;
  i[3456]86-*-aix*)        targ_emul=i386coff ;;
+ i[3456]86-*-sco3.2v5*)   targ_emul=elf_i386 targ_extra_emuls=i386coff ;;
  i[3456]86-*-sco*)        targ_emul=i386coff ;;
  i[3456]86-*-isc*)        targ_emul=i386coff ;;
--------------------- clip -------------------------------------

>Moreover, use of gnu ld may be required to use `libstdc++.a'.  Native
>ld fails to link programs using `string::npos' since that symbol gets
>multiply defined in `libstdc++.a' and user `*.o' that
>`#include<string>'.  This may be a reason for configuring gcc to use
>gnu ld.

 I haven't had problems with libstdc++ while building GCC and using
GNU ld in a cross-compile situation (RedHat6.2-Linux-x-sco3.2v5)...

>So I think that gnu ld on sco5 should be tested even now.

 Agreed... The problems with the previous "sco5 = svr4 + sco3.2"
approach should be told, otherwise it sounds like some people are
just trying to prevent others to build cross-tools for SCO5... 

>When I force to build current gnu ld on sco5 and test it on elf
>objects prepared as described above, it works normally unless it has
>to deal with (dynamic) `libc.so.1' overwritten by `OSRcompat' package
>from sco.  With native sco5 `libc.so.1' it is ok.

 Ok, here is one problem...

>`OSRcompat' is an add-on that enables binaries for later (unixware)
>system tu run on sco5.  It is required to run, e. g., jdk.  It puts
>unixware dynamic libraries in `/udk/usr/lib', but also overwrites
>`/usr/lib/libc.so.1'.
>
>After such an overwriting, all programs previously linked by native ld
>run without relink, and ld generates runnable programs normally.  Only
>gnu ld fails.  It generates program witch, when processed by ld.so,
>tries to link with libc from `/udk' rather than from `/usr/lib'.  This
>causes it to get undefined symbols and fail to run.

 What the executable does at run-time should depend on the 'libc.so'
etc. used when linking. My 'libc.so' for SCO5 (the original one) says
with 'objdump -p' :

------------------- clip -------------------------
Dynamic Section:
  INIT        0x1e7f0
  SONAME      /usr/lib/libc.so.1
  HASH        0xb4
  STRTAB      0xc000
  SYMTAB      0x2d80
  STRSZ       0x4f91
  SYMENT      0x10
  PLTGOT      0x58234
  PLTRELSZ    0x938
  PLTREL      0x11
------------------- clip -------------------------

ie. the executables linked against this will need the '/usr/lib/libc.so.1'
at run-time, like :

------------------- clip -------------------------
H:\usr\local\samples>\usr\bin\elf\objdump -p tst_sco5.x

tst_sco5.x:     file format elf32-i386

Program Header:
 <snip>
Dynamic Section:
  NEEDED      /usr/lib/libcrypt.so
  NEEDED      /usr/lib/libc.so.1
  HASH        0x80480e8
  STRTAB      0x804833c
  SYMTAB      0x804819c
------------------- clip -------------------------

 Normally the same 'libc.so' will be used both at link- and run-time,
but SCO5 seems to behave differently. The 'libc.so' seems to be an
archive containing the 'libc.so.1' and some other objects...

 Although the used 'libc.so' (in link-time) defines the run-time C-library
name, something in the executables can be changed using the linker options:

 o '-dynamic-linker=<dynamic_linker_name>' (which one to use at run-time),

 o '-rpath <path_to_the_dynamic-libs>' (where to look for the dynamic libs
   at run-time)

 o '-rpath-link <path_to_the_dynamic-libs>' (where to look for the dynamib
   libs at link-time)

 So using these may provide some kind of solution, using the 'objdump -p',
'readelf' etc. to look inside the executables may give more help...

>Overwritten `libc.so.1' somehow references /udk one: its `strings'
>output contains `/udk/usr/lib/libc.so.1'.  But native ld somehow
>bypasses this ref and directs ld.so to link with old (however
>overwritten) libc.  Gnu ld fails to do this.

 The "overwritten" is relative to what the sysadm lets happen... Copying
the original somewhere else and using it at link-time and at run-time
should be possible with the '-dynamic-linker', '-rpath' and '-rpath-link'
options, used when producing the executables...

 Lets hope this will get you find a solution to your problems...

Cheers, Kai