Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Need help with OpenVMS Linker warnings

Go to solution
Phil VanKley
Occasional Contributor

Need help with OpenVMS Linker warnings



I'm wrestling with some linker warnings.  I'm running VMS 8.3-1H1 and Oracle Rdb 7.2-400.  I am linking a COBOL application.  The link statement is below.  All of the subroutine objects, including the one referenced in the warnings (RDB$GET_RES_PHASE) is in the MCT$LIB:OBJLIB.OLB object library that is referenced in the link command.


$ link/executable=MCT$EXE:   mct$obj:PROCESS_RES_APPROVE.OBJ,      sql$user/lib,
%ILINK-W-NUDFSYMS, 2 undefined symbols:
%ILINK-I-UDFSYM,        VMH$FIXEDQ_UR (Weak Reference)
%ILINK-I-UDFSYM,        VMH$FIXEDQ_UW (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_GET_VM (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACK_GET_VM (Weak Reference)
%ILINK-W-USEUNDEF, undefined symbol SQL$RUNTIME_HANDLER referenced
        section: $LINKER UNWINFO$
        offset: %X0000000000000088
        module: RDB$GET_RES_PHASE
        file: USER1:[MCT_DEV.LIB]OBJLIB.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SQL$INIT_HANDLER_5 referenced
        section: SQL$MACRO_CODE
        offset: %X0000000000001070  slot: 2
        module: RDB$GET_RES_PHASE
        file: USER1:[MCT_DEV.LIB]OBJLIB.OLB;1


Now, I can get a successful link if I create an options file and link as follows:







Can anyone explain why the options file works where I explicitly specify this particular object in an INCLUDE specification when the objects for the included routines are in the object library referenced by the MCT$LIB:OBJLIB/LIBRARY reference in the original link command at the top of this post?


Ideally, I'd like to get the link to work, if possible, without an options file as this is an automated build system utilizing MMS and this particular executable link is the only one exhibiting this issue.




Phil Van Kley

Maricopa County Treasurer's Office

Phoenix, AZ




P.S. This thread has been moved from OpenVMS>General to Languages and Scripting board- Forum Moderator

Honored Contributor

Re: Need help with OpenVMS Linker warnings

The linker options file is a common portion of a link command and quite commonly used, and the /INCLUDE references here bring in the rest of the dependencies that then resolve the rest of the Rdb-related symbols and routines; it's the reference that pulls in the rest of the Rdb SQL environment.


(I don't recognize the RDB$GET_RES_PHASE symbol; the usual /INCLUDE I've created and used has had different Rdb-related symbols referenced.)


As for some background on this issue, please see the Oracle Rdb Guide to SQL Programming (that's V7) documentation for your Rdb version, among other available resources. And see information such as the following quote from the help text for SQL70:



When users link programs, they must somehow specify the SQL
interface user library SQL$USER.OLB. If you define the logical
name LNK$LIBRARY as the user library, you save users from having
to explicitly specify that library each time they link their
embedded SQL programs.

To define LNK$LIBRARY, issue this command:


To make sure LNK$LIBRARY is defined each time the system starts
up, add the previous command to the SYS$STARTUP:RMONSTART.COM
command file.

You must also check to see that the system logical name
LNK$LIBRARY is not already being used. Your site or other
products may have already defined the LNK$LIBRARY logical
name. If so, you should add a numeric suffix to the LNK$LIBRARY
definition you create and to the definition in RMONSTART.COM.
See the Oracle Rdb7 Installation and Configuration Guide for more
information about adding a suffix.

If you do not define LNK$LIBRARY to specify the SQL user library,
users must explicitly name it when they link programs with
embedded SQL statements. For example:


See the OpenVMS documentation set for more information about the
LINK command.



I tried quoting that text, but the forum software didn't allow it.


And FWIW, the linker options file is also how identification strings, shareable image match values and the rest of the settings are incorporated into the executable and shareable images that are getting created by the linker commands.  It's quite commonly encountered.


If I get a chance, I'll look up one of the example linker commands around, but the Rdb manuals do have the references to this stuff.

Phil VanKley
Occasional Contributor

Re: Need help with OpenVMS Linker warnings

Thanks for the quick response!  Note that I do have the SQL$USER library referenced in the original link command that results in the warnings.


We do links with Rdb-contained routines all the time.  For some reason, this is the only executable out of the other hundreds we have that has this issue.

Phil VanKley
Occasional Contributor

Re: Need help with OpenVMS Linker warnings

I did try defining the LNK$LIBRARY as specified in the documentation reference (DEFINE/SYSTEM/EXEC LNK$LIBRARY SQL$USER).  After doing this, my original link command was successful with no warnings.  Obviously, it is doing more with this logical name than the explicit reference to SQL$USER/LIB I have on the link command line.  I don't understand enough about how the linker works, though, to know why.


I will look deeper into my Rdb documentation concerning this as you suggested.  Thanks again so much!




Honored Contributor

Re: Need help with OpenVMS Linker warnings

FWIW, I usually use LNK$LIBRARY (possibly with the LNK$LIBRARY_sequence-number definitions, when working with a number of libraries) via DEFINE /NOLOG or DEFINE /JOB /NOLOG either at login or at the top of the DECset MMS, mmk or gmake, when I'm using that approach.  (And when I'm spending more time tussling with the make tools.)  Defining these logical name settings system-wide can (will) cause problems when using multi-version Rdb.  (If you are running multi-version Rdb, then there are set-up tools that establish a pile of definitions in the user's job context for you.)  And when working with logical names, these make tools create subprocesses so DEFINE [/PROCESS] works when invoked at the top level, but the setting won't be maintained and won't propagate when invoked within a subprocess.

Phil VanKley
Occasional Contributor

Re: Need help with OpenVMS Linker warnings

Good point on the rdb multiversion.  I am not running multi-version now but may down the road.  I'll look at implementing the process or job define approach in our build procedures.  Thanks so much for your assistance on this!




Steven Schweda
Honored Contributor

Re: Need help with OpenVMS Linker warnings

Honored Contributor

Re: Need help with OpenVMS Linker warnings

>Only a sissy uses LNK$LIBRARY. (It's too easy to leave it defined, and mess up future link jobs.)


Ayup.  But that's also the OpenVMS way, what with examples including the LNK$LIBRARY* definitions, the DECC$* settings, ALPHA$LIBRARY and IA64$LIBRARY, the JAVA$* settings, the GNV logical names and environment settings and login files, and a whole host of similar context-specific and non-volatile settings that are around on VMS.  This is unfortunate; that none of this ever got rolled into an architected management interface.


Steven Schweda
Honored Contributor

Re: Need help with OpenVMS Linker warnings

Honored Contributor

Re: Need help with OpenVMS Linker warnings

>>> Obviously, it is doing more with this logical name than the explicit reference to SQL$USER/LIB I have on the link command line.  I don't understand enough about how the linker works, though, to know why.

Just look at HELP LINK /USERLIBRARY: The OLBs pointed to by LNK$LIBRARY are searched after all specified input files have been processed. You then specified SQL$USER once as an input file on the command line and a second time with this logical. The second search/processing of the OLB resolved the undefined symbols.
And yes, it is the same as if you had the same library a second time on the command line.
John Gillings
Honored Contributor

Re: Need help with OpenVMS Linker warnings



   As you've probably gathered from the comments so far, linker processing is strictly left to right. At any point in link processing there is a set of unresolved references. If the next entity in the link list is a library, it is searched to try to resolve anything missing. Each new module may also add more references. After scanning a library, if new references were found, the library is scanned again, repeating until no new modules are resolved. Once a library is exhausted, it is forgotten.


  That means the order of libraries in the link list can be important. Typically the list should be from "high level" to "low level" left to right. If modules you know are present aren't being resolved, reordering the libraries may fix the problem. In your case, if OBJLIB makes references to SQL, it should be moved to the left of SQL$USER. Occasionally you'll find a pair of libraries with circular references, so library A makes references to modules in library B and library B has references to modules in library A. In this case, one way to resolve the circularity is to repeat the libraries:




(in extreme cases you may need more repeats). Arguably these libraries are poorly structured. If they're your own code, perhaps they could be combined into a single library, or reorganised to break the circularities. Even if they're not your own code, the librarian is fast enough that for libraries in the size range of SQL$USER, you could extract all modules from multiple libraries and create a new, combined, temporary library for the duration of the link, without really noticing. Another option is to use /INCLUDE, or have a module with unreachable references to force inclusion of all the necessary modules.


Use $ LINK/MAP/FULL/CROSS to get an idea of which modules are involved in the circularity, and the order of resolution.


Once you understand the way link processing works, and the dependence tree of your code, it should become clear how to structure the LINK command.

A crucible of informative mistakes
Dennis Handly
Acclaimed Contributor

Re: Need help with OpenVMS Linker warnings

>linker processing is strictly left to right.


This is exactly the same as the linker on HP-UX when dealing with archive libs.

(With shared libs it doesn't matter so much since they are searched at runtime.)

Also if you don't want to add duplicates or think hard about ordering, the linker provides a +n option that goes back to the beginning of the list and searches until no more modules are added.

Ph Vouters
Valued Contributor

Re: Need help with OpenVMS Linker warnings


Your HP-UX ld statement with archive libraries versus dynamic libraries is also true on Linux and ought to be identically true on any proprietary/non proprietary Unix aware operating system.

As the VMS is unable to do a implicit dynamic link, all dynamic libraries (shareable images) references must be solved statically by the VMS linker.
Honored Contributor

Re: Need help with OpenVMS Linker warnings

>>>linker processing is strictly left to right.

It depends. Did you ever wonder why these linker guys put the "Object Module Synopsis" into the map file? Once you use clusters the order may not be what you expect as "left to right".
Create a main.obj with a reference to symbol sub1 and sub2 defined in the object sub1.obj and and the shareable image sub2.exe. Create a object library s.olb and add sub1.obj and another independent object any.obj (which is not referenced but which you always want to have in your image).
On Alpha...
$ link/map=main/full/cross/exe=main tt:/opt
[ Exit ]
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM,         SUB1 
%LINK-W-USEUNDEF, undefined symbol SUB1 referenced
        in psect $LINK$ offset %X00000030
        in module MAIN file SYS$SYSDEVICE:[HARTMUT]MAIN.OBJ;1
The order of processing input files is defined by the linker clusters and the file order, known as "left to right". User clusters come first, then other clusters.
In the map you will see in the Object Module Synopsis the modules SUB2, ANY and MAIN (plus DECC$SHR, SYS$PUBLIC_VECTORS) and their corresponding files.
In the Image Section Synopsis you will see the clusters SUB2, SUB1 and DEFAULT_CLUSTER (plus DECC$SHR, SYS$PUBLIC_VECTORS).
With sub2/share you define the first user, or non-default cluster, so sub2.exe is processed first. With main you do not define a user cluster, so main will go to the default cluster, which will be processed later. With cluster=sub1 you define the second user cluster so s.olb is processed next. Here only the module any is included: there is no reference to the symbol sub1, yet. No more user cluster, now process main.obj which is the first module on the default cluster. It references sub1 which is not yet defined and will not be resolved by any subsequent input file (DECC$SHR, SYS$PUBLIC_VECTORS).
Obviously, shareable images are handled differently than object modules: when sub2 is processed, there is no reference to the symbol sub2.
And yes, if you put main on a user cluster the link completes without a problem.
>>> As the VMS is unable to do a implicit dynamic link...
VMS and the executable image format were never designed for dynamic linking. The symbols in a shareable image are for the linker and lib$fis. There are no symbols in main images: no symbol reference to a shareable image. As a result, VMS can't do symbol pre-emption. That's a main difference to Unix/Linux.