| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5278.1 | Try dynamic instead of static linking | TLE::D_SMITH | Duane Smith -- DEC C RTL | Wed Feb 26 1997 09:50 | 33 |
| Since no one chimed in here, I'll give it a shot. Your application is
linking against SYS$LIBRARY:UCX$IPC_SHR.EXE, which in turn is linked
against several shareable images, one being UCX$ACCESS_SHR. The image
activation list recorded in your image contains the transitive closure
of all images involved, including UCX$ACCESS_SHR.
Take the following example:
$ TYPE TEST.C
#include <stdio.h>
main () {
printf ("Hollow world\n");
}
$
$ CC TEST
$ LINK TEST, SYS$INPUT/OPT
SYS$SHARE:UCX$IPC_SHR.EXE/SHARE
$
$ ANALYZE/IMAGE/OUTPUT=TEST.ANALYZE TEST.EXE
If you look at the result of the ANALYZE/IMAGE, you will see a
reference to UCX$ACCESS_SHR in the list.
To resolve this problem (and perhaps future problems such as this), I
would use LIB$FIND_IMAGE_SYMBOL to dynamically link against
UCX$IPC_SHR.EXE instead of the static link. In this way, you are
deferring the activation of UCX$IPC_SHR and in the case of UCX, the
activation of UCX$ACCESS_SHR. If Multinet does not have this secondary
shareable image, then it will not be activated.
Duane Smith
OpenVMS DEC C RTL Project Leader
|
| 5278.2 | | LASSIE::GEMIGNANI | | Wed Feb 26 1997 13:40 | 12 |
|
Keep in mind that your application is bound to use the UCX databases
(i.e. hosts, etc) when you link with IPC_SHR. It is calling ACCESS_SHR
to be able to provide access to UCX databases.
I suspect that the other vendors supply a replacement UCX$IPC_SHR so
that you can get to their databases. Either that, or you link without
UCX$IPC_SHR.
The problem with .-1 is that you are calling certain UCX$ routines to
provide network access, i.e. gethostbyname() and so on. You are going
to need some way to get those routines.
|
| 5278.3 | | TLE::D_SMITH | Duane Smith -- DEC C RTL | Wed Feb 26 1997 15:35 | 5 |
| Actually, I would prefer to see the customer make calls to the DEC C
Runtime Library... We do dynamic linking and work fine with other
vendors stacks...
Duane
|
| 5278.4 | | LASSIE::GEMIGNANI | | Wed Feb 26 1997 18:14 | 2 |
| Oooh. Then why's he linking with IPC_SHR?
|
| 5278.5 | Light dawns... | OSEC::LUNN | [email protected] | Thu Feb 27 1997 05:35 | 10 |
|
Thanks for the responses. As you suggest, there's no need to link
against UCX$IPC_SHR at all in this case - using the standard C routines
makes everything work just fine on all three platforms.
Just out of interest, why *would* you link against UCX$IPC_SHR?
Thanks again for the insight,
Dave.
|
| 5278.6 | left over from a VAXC build environment maybe? | HNDYMN::MCCARTHY | A Quinn Martin Production | Thu Feb 27 1997 09:18 | 8 |
| In the past, many linker options files "grew" from using VAXC. There should
have been a rule that any linker options file was thrown out when moving to
DECC.
I'm not saying that is what happened in this case, its just something I have
seen in many public domain examples.
bjm
|