|
HP OpenVMS Systemsask the wizard |
|
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.
|