Linker Issues with OpenVMS Itanium?

[Manesh Sasankan]

I'm using OpenVMS Itanium V 8.2-1.I use a C-code base which get build using the make-style scripting (MMS). The entire code base is new and the C files are compiled fully & when the linking process starts, it throws this error of UNDEFINED SYMBOLS being REFERENCED.Something like this

%ILINK-W-USEUNDEF, undefined symbol X_RESTOREMAIN referenced
section: $CODE$
offset: %X00000000000010B0 slot: 1
module: RS1SUBEN
file: DDE$ROOT:[LIB]CALLABLE.OLB;1

And it generates a bunch of similar errors.

I have a similar code base (which i used before) which still is working perfectly fine.

And both these code bases reside in 2 different accounts in the same disk(same device name too like DKA0:[xxxx] & DKA0:[yyyy]) of the same machine. I didn't face any linker issues in the previous code base. We use 2 different disk, 1 is used for all the development activities & the the other for the testing purposes.

The CC Command used to compile both the code base are the same.

Is this related to code?. Is it possible to pass some parameter to the linker so that it will link properly or is there any other changes that needs to be included with the linker.

This is an urgent issue for me. so appreciate if you could comment on this...

/Manesh

[Wim Van den Wyngaert]

The thing that is different is only the account ? Then check the login.com for differences.

Or do @dka0:[yyy]login.com when logged in as xxx. And then try to link again.

Or may be some object is present that is newer than the C file but is not corresponding to the C file. Remove them all and recompile.

Wim

[Hein van den Heuvel]

I suspect a simple coding error, like X_RESTOREMAIN used when X_RESTORE_MAIN declared. Is this application C++ and case sensitive?

This symbol "X_RESTOREMAIN", what do you know about it? Is it suppoed to be used from RS1SUBEN? If so, where is it supposed to be declared? Is that place explicitly inluded in the link (mentioning the .OBJ file) or implicitly (in a .OLB library to be search with /LIB).

Is that same symbol "X_RESTOREMAIN" used in the other code base in the other account? Where is it resolved from? To find out use a LINK/MAP/CROSS on the other account, and $SEARCH x.MAP X_RESTOREMAIN
hth,
Hein.

[Dean McGorrill]

hi Manesh,
I used to run across stuff like this
all the time, which is one reason I built
our large codebase regularly. Do you have
library control, like cms? you might be able to find more by a cms sho history/trans=replace/since=dd-mmm-yyyy
where the date is when it last linked ok.
also sear the entire for reference to
X_RESTOREMAIN, make sure its compiled and
you'll know where to link against it. if
its new development it may need to go into
a library. It often is brute force searching
to solve, a pain I know.

[Manesh Sasankan]

Hi Dean,

i tried this:

CMS> sho history/trans=replace/since=20-jan-2007

%CMS-E-NOREF, error referencing CMS$LIB:
-CMS-E-USESETLIB, use SET LIBRARY
& i got this error..

How to set a library? i tried to give the directory where the correct olb file was located and it say that that it is not a CMS LIBRARY.

??

Manesh

[Dean McGorrill]

ask someone whos doing the development work
if they use cms. if so wheres the library(s)
at. (Hope that they use some kind source
control!)

[Manesh Sasankan]

Dean,

Thanks a ton for your response. No one used cms before here. This is an urgent requirement for me & i'm not that good in VMS :-).

when u say library, in vms what exactly do that mean. Is it a olb file or obj file or ??. i'm pretty sure that we never used source control in vms( to make things worse).

I found one more thing. The X_RESTOREMAIN() is defined in X.C & XX.c in a different directory. It also has a "extern reference" in a XXX.H file.

Now this function is called in 3 different C files and for all these, the linker generated the same error.

In x.c & xx.c, the func is defined as

VOID X_RESTOREMAIN()
{
--
}

In XXX.h,

extern void X_RESTOREMAIN()

And for the 3 different C files, it's called like:

X_RESTOREMAIN()

It's all over the place!!!

manesh

[Hein van den Heuvel]

>> The X_RESTOREMAIN() is defined in X.C & XX.c in a different directory

So which one is right?
And how is the linker supposed to find that one?

As per my earlier reply.
Assuming x.c is compiled to become x.obj
Either add [otherdirectory]x.obj in the link command with the other objects,
or, stick it in a library which will be searched.

Specifically you may want to try
$LIBR/INSERT DDE$ROOT:[LIB]CALLABLE.OLB [otherdirectory]x.obj
If that complains about about the module already existing, then you may try LIBR/REPLA instead.
If you are not entirely sure, then you may want to do a $LIBR/EXTRACT... on the module before a REPLACE.
Or use LIBR/LIST/NAME to learn details.

hth,
Hein.

[Dean McGorrill]

Manesh,
a cms library usually looks something like..

00CMS.CMS;1 01CMS.CMS;1 01CMS.HIS;1

and found in sub directorys. Its moot because you said noone uses it!

Heins right, compile it and probably sticking it in the library
is your best bet.

[John Gillings]

Manesh,

Without seeing your LINK command it's difficult to give a good diagnosis, however, when you say there are two different locations for the object code, perhaps this is a library order sensitivity?

Consider:

$ LINK main+A/LIBRARY+B/LIBRARY

If there is a module in library A referenced only from module(s) in library B, the linker will report USEUNDEF because by the time the reference is discovered, library A is no longer a link candidate.

Bottom line is to find the unresolved symbols in your libraries and object modules, and ensure they're ordered correctly.

Sometimes the solution is to reorder yuor libraries, for example:

$ LINK main+B/LIBRARY+A/LIBRARY

or, if there are circularities, perhaps repeat a library:

$ LINK main+A/LIBRARY+B/LIBRARY+A/LIBRARY

(however, this would usually represent a structure clash, which would be better resolved by redistributing modules between libraries).