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

!DEC$ ATTRIBUTES & Linking

 
SOLVED
Go to solution
Chrispy
Occasional Visitor

!DEC$ ATTRIBUTES & Linking

I have recently added the !DEC$ ATTRITUBES ADDRESS64 statement to my program for a few of the variables. Before this was added, the program would link with no errors or warnings, now that the statement is added in, a set of warnings pops up when I try to link. An example is

%LINK-W-UDEFCLI, attempt to reference undefined conditional linkage index 10. in module SOLN file TEMP.OBJ;101

There are about 40 of these and I have tried moving the routines in the fortran file around and have managed to eliminate a few of them, but got to a point where I seem to be going in circles. The program still runs fine, but I would like to link with no warnings. Any help would be appreciated.
4 REPLIES 4
Hoff
Honored Contributor

Re: !DEC$ ATTRIBUTES & Linking

The following assumes you're not using this Fortran DEC$ ATTRIBUTE with subprogram specifications, nor with EXTERNAL statements. If you're not current on your OpenVMS and Fortran and ECO versions, consider getting there. If you've not rebuilt everything involved here (your source code, your library contents, etc) with current tools, consider that.

As for the error itself, this looks like a bug in either the compiler or the linker. To wit:

UDEFCLI, attempt to reference undefined conditional linkage index
'decimal-number' in module 'module-name' file 'file-name'

Facility: LINK, Linker Utility

Explanation: A module references an undefined linkage pair.

User Action: Contact HP Customer Support about the appropriate language
processor.


The folks at the support center will likely want the version information, and access to the source code (or a source code reproducer)... (And they'll almost certainly ask you to "get current" on your versions, too.)

Post back what the HP folks tell you.
Chrispy
Occasional Visitor

Re: !DEC$ ATTRIBUTES & Linking

We have just found what may have been the problem. Before we were compiling with the /separate_compilation command and we removed this and the errors no longer popped up (we also reorganized the order of the files in the link command). Thank you for your help.

We have found another problem though. When we try to create a library from a file that contains the !DEC$ ATTRIBUTES ADDRESS64 line, we get this error:

%LIBRAR-E-GSDTYP, module NAME file LIBRARY.OBJ;31 has an illegal GSD record (type 9)

and we cannot create a library out of it. Any ideas?
John Gillings
Honored Contributor

Re: !DEC$ ATTRIBUTES & Linking

Chrispy,

Unfortunately converting a program to 64 bit addresses is rarely as simple as turning an attribute switch. There are many ways a program can have implicit assumptions as to sizes and locations of objects. I'd guess that the errors you're seeing are due to mismatches between 32 and 64 bit.

I'd recommend identifing which objects or parts of your code need to be 64 bit and isolate them into separate modules. Get those modules building cleanly and work outwards.
A crucible of informative mistakes
x2084
Trusted Contributor
Solution

Re: !DEC$ ATTRIBUTES & Linking

The UDEFCLI warnings are related to linker optimizations, which are on by default: /replace. The linker tries to replace some JSRs with BSRs but can't. Without seeing a linker map, or the object modules or output from analyze/object it is hard to say if this is the case, here.

Such problems show with big modules which are collected into big image sections or even more than one section. As you say, the image runs fine and it is expected that this warning does not affect the correctness of the generated image. /NOREPLACE is expected to avoid the warnings but that qualifier will suppress all linker optimizations.

There is not much you can do to avoid the problem. Rearranging the order of processing may avoid help, because PSECTs are layed out differently in the image sections. This way it may be possible to replace all JSRs. But if you make some sections bigger, it may show again.

For the librarian problem, there should be a fix available. At least there was a fix made more than a year ago.