topic Re: Need help with OpenVMS Linker warnings in Operating System - OpenVMS

Need help with OpenVMS Linker warnings

Phil VanKley — Mon, 17 Oct 2011 06:55:50 GMT

Hello,

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,
   mct$lib:objlib.olb/lib
%ILINK-W-NUDFSYMS, 2 undefined symbols:
%ILINK-I-UDFSYM,        SQL$INIT_HANDLER_5
%ILINK-I-UDFSYM,        SQL$RUNTIME_HANDLER
%ILINK-I-UDFSYM,        VMH$FIXEDQ_UR (Weak Reference)
%ILINK-I-UDFSYM,        VMH$FIXEDQ_UW (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_FREE_VM (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_FREE_VMLIST (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_GET_VM (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACE_RET_VMH (Weak Reference)
%ILINK-I-UDFSYM,        VMHDEB$TRACK_FREE_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:

PROCESS_RES_APPROVE.OPT:

MCT$LIB:OBJLIB/INCLUDE=(GET_RES_PHASE,RDB$GET_RES_PHASE)
SQL$USER/LIBRARY
MCT$LIB:OBJLIB/LIBRARY

$ LINK/EXE=MCT$EXE: MCT$OBJ:PROCESS_RES_APPROVE, MCT$LIB:PROCESS_RES_APPROVE/OPT

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.

Thanks!

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

Re: Need help with OpenVMS Linker warnings

Hoff — Sat, 15 Oct 2011 15:38:46 GMT

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:

$ DEFINE/SYSTEM/EXECUTIVE/NOLOG LNK$LIBRARY SQL$USER

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:

$ LINK my_prog, SQL$USER/LIBRARY

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.

Re: Need help with OpenVMS Linker warnings

Phil VanKley — Sat, 15 Oct 2011 15:45:56 GMT

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.

Re: Need help with OpenVMS Linker warnings

Phil VanKley — Sat, 15 Oct 2011 15:57:45 GMT

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!

Phil

Re: Need help with OpenVMS Linker warnings

Hoff — Sat, 15 Oct 2011 16:10:37 GMT

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.

Re: Need help with OpenVMS Linker warnings

Phil VanKley — Sat, 15 Oct 2011 16:33:13 GMT

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!

Phil

Re: Need help with OpenVMS Linker warnings

Steven Schweda — Sat, 15 Oct 2011 20:01:38 GMT

Re: Need help with OpenVMS Linker warnings

Hoff — Sat, 15 Oct 2011 20:28:00 GMT

>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.

Re: Need help with OpenVMS Linker warnings

Steven Schweda — Sun, 16 Oct 2011 19:07:54 GMT

Re: Need help with OpenVMS Linker warnings

H.Becker — Sun, 16 Oct 2011 20:45:26 GMT

>>> 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.

Re: Need help with OpenVMS Linker warnings

John Gillings — Mon, 17 Oct 2011 20:59:26 GMT

Phil,

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:

$ LINK x,A/LIBRARY,B/LIBRARY,A/LIBRARY

(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.

Re: Need help with OpenVMS Linker warnings

Dennis Handly — Tue, 18 Oct 2011 18:08:51 GMT

>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.

Re: Need help with OpenVMS Linker warnings

Ph Vouters — Wed, 19 Oct 2011 15:10:29 GMT

Denis,

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.
Kind

Re: Need help with OpenVMS Linker warnings

H.Becker — Wed, 19 Oct 2011 20:42:35 GMT

>>>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

sub2/share

main

cluster=sub1,,,s/lib/incl=any

[ 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.