bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnu ld on sco5


From: Голубев Илья Н.
Subject: gnu ld on sco5
Date: Thu, 10 May 2001 16:44:43 (GMT)

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.
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.

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.

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

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.

`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.

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.

I still have debuggable gnu ld and all aelf object I linked, including
native and `OSRcompat' libc, so you can request from me additional
info concerning system behavior.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]