Need help with OpenVMS Linker warnings

[John Gillings]

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.

[Dennis Handly]

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

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

[H.Becker]

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