[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnu ld on sco5
From: |
Kai Ruottu |
Subject: |
Re: gnu ld on sco5 |
Date: |
Tue, 16 May 2000 10:22:48 GMT |
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