 |
The Question is:
I have the task of maintaining the software for a VMS application .EXE written
in C and Macro which I compile, produce .OLBs and link to produce a monolithic
executable .EXE. Some of the C and macro function reference system defined
symbols e.g. CSB$V_MEM
BER, DVS$_DEVCLASS and many more.
I have 'moved' all the macro code and some of the C functions that use these
symbols so that they now reside in a shareable EXE that I link against when I
produce the executable.
I can successfully produce the shareable use /SYSEXE in the linker command: but
when I link against it to produce the executable I get a whole bunch (137 in
total including the two quoted above) undefined symbols. There are references
to these symbols in
the code that is not in the shareable EXE. I can reduce the problem by moving
more code into the shareable but there is one function that would require a
significant redesign if it were to be moved.
I understand from the linker documentaion that
'For Alpha linking, the linker does not process the shareable images that the
shareable image you specify has been linked against. (Shareable images on
Alpha systems still contain GISDs for each shareable image that they have been
linked against, however.
) If your application's build procedure depends on implicit processing of
shareable images, you may need to add these shareable images to your linker
options file.'
How do I instruct the linker to resolve the symbols ? Is there a combination of
/(NO)SYSEXE, /(NO)SYSSHR, (NO)SYSLIB and/or an explicit specification of a
system library in the options file. If so what is it ?
You can see from my two link commands that follow that I have a fairly complex
build environment that is configured by the DCL symbols. The only one of
interest here is probably SYSEXE_Q that would normally hold "/SYSEXE".
$! build the library to link against because the LINK does not allow wild cards.
$ LIBRARY/CREATE
COLL:COLLECTOR_SHR.OLB_'ARCHITECTURE'_'REQ_VMS_VER''VARIANT''LIB_FOR''LIB_DBG'_
DEF *.OBJ_DEF
$! create the 'default' shared EXE
$ LINK /SHAREABLE=COLI:COLLECTOR_SHR.EXE -
/SYSEXE -
COLL:COLLECTOR_SHR.OLB_'ARCHITECTURE'_'REQ_VMS_VER''VARIANT''LIB_FOR''LIB_DBG'_
DEF/LIB, -
COLL:COLLECTOR.OLB_'ARCHITECTURE'_'REQ_VMS_VER''VARIANT_ABBR''LIB_FOR''LIB_DBG'
/LIB,-
VARL:VARIABLES.OLB_'ARCHITECTURE'_'REQ_VMS_VER''VARIANT_ABBR''LIB_FOR''LIB_DBG'
/LIB,-
UNIL:UNIVERSE.OLB_'ARCHITECTURE'_'REQ_VMS_VER''VARIANT_ABBR''LIB_FOR''LIB_DBG'/
LIB,-
SYS$INPUT/OPT
GSMATCH=always,0,0
SYMBOL_VECTOR=(-
UNI_GBL=DATA,-
COL_GBL=DATA,-
COA_GBL=DATA,-
VAR_GBL=DATA,-
COA_CLUSTER_STATS=PROCEDURE,-
COA_CONFIG_STATS=PROCEDURE,-
COA_DEVICE_STATS=PROCEDURE,-
COA_DEVNAM_LIST=PROCEDURE,-
COA_GSD_STATS=PROCEDURE,-
COA_NPAGED_POOL=PROCEDURE,-
COA_PAGE_FAULTS=PROCEDURE,-
COA_SUM_GLOBAL=PROCEDURE,-
COA_COMPUTE_CPU_SPEED=PROCEDURE,-
COA_KERNEL_CLUSTER=PROCEDURE,-
COA_KERNEL_CLUSTER_CNT=PROCEDURE,-
COA_KERNEL_CONFIG=PROCEDURE,-
COA_KERNEL_DEVICE=PROCEDURE,-
COA_KERNEL_DISKIO=PROCEDURE,-
COA_KERNEL_FAULTS=PROCEDURE,-
COA_KERNEL_GSD=PROCEDURE,-
COA_KERNEL_LOCK=PROCEDURE,-
COA_KERNEL_MEMORY=PROCEDURE,-
COA_KERNEL_MODES=PROCEDURE,-
COA_KERNEL_MSCP=PROCEDURE,-
COA_KERNEL_NPAGED=PROCEDURE,-
COA_KERNEL_PAGED=PROCEDURE,-
COA_KERNEL_PRCCNT=PROCEDURE,-
COA_KERNEL_PRCCRE=PROCEDURE,-
COA_KERNEL_PROCESS=PROCEDURE,-
COA_KERNEL_RESOURCE=PROCEDURE,-
COA_KERNEL_RVT=PROCEDURE,-
COA_KERNEL_SCSCON=PROCEDURE,-
COA_KERNEL_SHRLNM=PROCEDURE,-
COA_KERNEL_SUMGBL=PROCEDURE,-
COA_KERNEL_SWPCPU=PROCEDURE,-
COA_KERNEL_VOLSET=PROCEDURE,-
COA_LOCK_CODE=PROCEDURE-
)
and
$ LINK_RULE_ENGINE:
$! switchoff the sysex qualifier while we specify base_image explicitly
$! SYSEXE_Q = ""
$! JWT 1-nov-2001 addition of usv_udt_last_error requires usvl after fill
$ LINK'LINK_DBG''NONATIVE_Q'/TRACE'SYSEXE_Q'/NOUSER/-
EXE=ROBI:RULE_ENGINE.EXE_'ARCHITECTURE'_'REQ_VMS_VER''LIB_FOR''LIB_DBG''SERVICE
_PACK'/-
MAP=ROBM:'VARIANT_LIT'_RULE_ENGINE.MAP_'ARCHITECTUREp
The Answer is :
Please see the shareable image cookbook (available here in the
Ask The Wizard area) and see the linker manual for details on
the /SHARE and /SYSEXE qualifiers. (/SYSEXE implies the code
is linked against the OpenVMS Alpha kernel.)
The symbols you reference appear to be standard definitions
from OpenVMS include files, and would be resolved using the
default path (SYS$STARLET_C.TLB for public definitions) or
by specifying the SYS$LIB_C.TLB library (for inner-mode and
for internal definitions) on the compilation command.
For details on the C compilation command, please see the C
compiler documentation.
If this is a User Written System Service (UWSS) or
otherwise operating in executive or kernel mode, you will
want to use /NOSYSLIB to disable access to the user-mode
RTLs including the user-mode C RTL. (Inner-mode code
cannot reference the user-mode RTLs including the user-mode
C RTL and particularly cannot use user-mode RTLs to manage
the image heap and application memory.) Inner-mode C code
should use the kernel-mode C RTL.
CSB$V_MEMBER is present in csbdef in SYS$LIB_C, and can be
referenced by include statement referencing csbdef.h in
the code, and a compilation qualifier referencing the
SYS$LIB_C.TLB library.,
As has been sited elsewhere, please see the OpenVMS FAQ for
common C coding questions and discussions, please see topic
(1661) for programming errors and considerations (and pointers
to related topics), please see the compiler documentation,
and please see the shareable image cookbook.
For related programming assistance and for information on
available training programs, please consider contacting
your prefered provider and/or HP Services.
|
|
|
|
|
