wedekind@arisia.Xerox.COM (Jerry Wedekind) (01/19/89)
The World:
gcc 1.32.0 (configured by "config.gcc sun3-os4")
g++ 1.32.0
tm.h -> tm-sun3+.h // Configured in accordance with SUN3.README
md -> m68k.md
aux-output.c -> output-m68k.c
config.h -> xm-sunos4+.h
I made some changes to xm-sunos4.h (both to get it to work & from advice
on the net)
#define LINK_SPEC "%{!e*:-e __start} -dc -dp %{static:-Bstatic}"
Everything works fine. I can compile all the test cases in the libg++
1.32.0, and our own tiny code seems to work.
The problem is when we try to use the Sun supplied libraries.
libsunwindow.a in particular. When we try to link with this library
(-lsunwindow) we get:
Undefined symbols:
__DYNAMIC
Using "strings" on all the standard libraries (/lib and /usr/lib) shows
that libsunwindow.a is the only library that has this string. According to
the Sun man page on "ld", this has something to do with dynamic linking.
(The relevant sections are quoted below).
By the way, gcc (1.32.0) has no problem using the same library (in
completely parallel C code).
Does anyone have a fix or a work around??
Thanks,
/John
arpa: JWenn.esae@Xerox.com
wedekind@arisia.com
------------------------------------------------------------
[From Sun ld.1 man page, copyright 1988 Sun Microsystems]
Special Symbols
A number of symbols have special meanings to ld and programs
should not define these symbols. The symbols described
below are those actually seen by ld. Note: C and several
other languages prepend symbols they use with `_'.
__DYNAMIC
Identifies an ld-produced data structure. It is
defined with a non-zero value in executables which
require execution-time link editing. By convention, if
defined, it is the first symbol in the symbol tablen
associated with an a.out file.
<...>
Execution-Time Loading
In the event that one or more reductions can not be com-
pleted, the executable will require further link editing at
execution time in order to be usable. Such executables con-
tain an data structure identified with the symbol __DYNAMIC.
An incompletely linked main program should be linked with a
bootstrap routine that invokes ld.so, which uses the infor-
mation contained in the main program's __DYNAMIC to assemble
the rest of the executables constituting the entire program.
A standard Sun compilation driver (such as cc(1V)) automati-
cally includes such a module in each main executable.
When ld.so is given control on program startup, it finds all
.so files specified when the program was constructed (and
all .so's on which they depend), and loads them into the
address space. ld.so then completes all remaining reloca-
tions, with the exception of procedure call relocations;
failure to resolve a given non-procedural relocation results
in termination of the program with an appropriate diagnos-
tic.
Procedure relocations are resolved when the referencing
instruction is first executed. It should be noted that it
is possible for undefined symbol diagnostics to be produced
during program execution if a given target is not defined
when referenced.
Although it is possible for binding errors to occur at
execution-time, such an occurrence generally indicates some-
thing wrong in the maintenance of shared objects. ld's
-assert definitions function (on by default) checks at ld-
time whether or not an execution-time binding error would
occur.