linkin a version 6.6 object file with in an earlier CVF development environment

[rsampson]

I send a CVF 6.6 generated object file to a developer with an earlier CVF version, I believe he has version 6.5. When he compiles and links his codewith my .obj specified, he gets the unsatified external error message. We have carefully verified the number and type of call parameters to rule out a mismatch. Is this a version problem and if so is there a fix for it or have we overlooked something?

Incidentally I did a dumpbin on the .obj and got a byte count of 44. There are 8, 4 byte integers and 4, 8 byte reals in the call parameters. I would think this would give a count of 32+32=64. Is there something I don't understand about the dumpbin count? Could the unsatified external problem be related to this?

Thank you in advance,

Richard

[Steven_L_Intel1]

You didn't say what the unsatisfied reference was.

On the @n, this is not the number of bytes of the variables, but of what gets pushed on the stack for the call. In most cases, this is a 4-byte address for any kind of argument. CHARACTER arguments get an additional 4-byte length and if it's a function that returns a "big" value, there can be a hidden extra argument for the function return.

I would expect 4 integers and 4 reals to result in @32. Do you have any character arguments in there? Show the SUBROUTINE or FUNCTION line and the declaration of all the arguments.

[rsampson]

The unsatisfied reference was a call to a subroutine, amg,in my object code. The error message is reproduced below.

astap.for
proces.lib(matsin.obj) : error LNK2001: unresolved external symbol _amg@48
astap.exe : fatal error LNK1120: 1 unresolved externals

[Steven_L_Intel1]

Ok. Note that the name "amg" is in lowercase. Does that match what you see in your own object? That would not be the default for CVF.

Can you show the declaration of routine AMG and its argiments? Can you show the source of the call and declarations of its arguments?

[rsampson]

You have pinpointed the problem. I use uppercase for routine names. The person to whom I am sending the object code uses the compiler option /names:lowercase which caused the problem. I am now using the same option when compiling the object code.

Thanks very much for the help,

Richard