| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 488.1 | | QUARK::LIONEL | The dream is alive | Tue Mar 28 1989 14:59 | 3 |
| What are the symbols?
Steve
|
| 488.2 | Reply to .-1 undefined symbols with LIB$FIND_IMAGE | TOOLS::HOCHULI | | Wed Mar 29 1989 11:02 | 11 |
| When we link without DECW$DWTLIBSHR and DECW$XLIBSHR using
LIB$FIND_IMAGE_SYMBOL to load the DWT$, X$ and XT$ symbols we actually
reference we get 700+ undefines we don't reference but that are
referenced in the R32 BLISS require files supplied by DECwindows.
Examples are APPLICATIONSHELLCLASSREC, DWT$CLIPBOARD_LOCK,
X$SET_FUNCTION, XT$POPUP. We got LINK-W-USEUNDEF for the symbols we
referenced but forgot to load from LIB$FIND_IMAGE_SYMBOL but we've
cleaned them all up now. Is there a way to turn these messages off
in the linker?
|
| 488.3 | fool it | STAR::BRANDENBERG | Intelligence - just a good party trick? | Wed Mar 29 1989 11:11 | 7 |
|
I don't know of a way to suppress the messages in LINK or to prevent
BLISS from generating references in REQUIRE files (I didn't know it
created any, actually). You might use the SYMBOL option to force a
meaningless resolution of the symbols or create an object with the
necessary global symbols. It is ugly, but....
|
| 488.4 | | JHEREG::TANNENBAUM | TPU Developer | Wed Mar 29 1989 13:57 | 7 |
| I assume that you're trying to create an application which will work in both
the character cell and DECwindows worlds (or UIS). TPU faced the same problem.
We chose to write a separate screen updater which we image activate which is
linked against the DECwindows libraries.
- Barry
|
| 488.5 | Go for complete isolation | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Fri Mar 31 1989 16:21 | 19 |
| I was just going to suggest what Barry said...I think you are much better
off isolating ALL the dependencies in a dynamically loadable file than to
try to find figure out exactly what the dependencies are and then try to
make magic macros that redefine calls to call through a dynamically
constructed jump table, etc etc.
Note that doing what you are doing is likely to cause two copies of the
sharable image to be activated. This is because LIB$FIND_IMAGE_SYMBOL
uses a search tree to find out whether it has already activated a sharable
image. I suspect that if you, for example, dynamically activated both
the toolkit and Xlib that you would find that the toolkit would probably
activate a second copy (or at least a second mapping) of Xlib. The
likelyhood of "probably" depends on whether LIB$FIND_IMAGE_SYMBOL notices
that images that it activates also activate other images. I don't know for
sure, but I doubt it, since it is only a library routine, after all; it
should not have that much intimate knowledge of the internals.
Burns
|