Controling /FORCE:MULTIPLE

[dajum]

Hi,

I have a project that I compile a main routine and other routine and then link with a library. I want to override a routine that exists in the library by including a new routine of the same name in with the main routines compilation. Then have the linker ignore the version that exists in the library. Without /FORCE:MULTIPLE in the compile/link commands,I get an error. With it I get a warning, but it is using the routine out of the library. I expected that since the source file iscompiled that it would have first priority, but that isn't happening. I can tell by the output of the executable that the library version was used. How can I get it use the source?My compile link commmandfollows. ASTAP.FOR contains the new routine, and proces.lib contains the orignal routine of the same name thatI want to override.

astap.for /names:lowercase /Zi /Oy- /iface:cref /module:"c:v50ivfprocesproces___Win32_Release" /MT /libs:dll /iface:mixed_str_len_arg /include:c:v50ivfprocesproces___Win32_Release /nologo /assume:byterecl /extend_source:132 /optimize:5 /list /traceback /link /OUT:"astap.exe" /FORCE:MULTIPLE /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"msvcrt.lib" /SUBSYSTEM:CONSOLE c:v50ivfprocesproces.lib c:v50ivfutilutility.lib c:v50ivfprocesisight.lib c:v50ivfproces dsubproc.lib statwin.lib c:v50ivfprocessfmatlab.lib c:v50IVFutilutility.lib /MAP

Thanks,

Dave

[dajum]

Can anyone help even a little on this?

Thanks,

Dave

[Steven_L_Intel1]

What compiler are you using here? Some of the options suggest CVF.

Where is the main program coming from?

[dajum]

Thanks for looking Steve,

I'm using IVF 9.0.030. It was mutated from CVF. The main program is in ASTAP.FOR along with the routine I'm trying to use to replace the one of the same name in the library.

Dave

[Steven_L_Intel1]

I created my own example of this in 10.1 and VS2005 and it worked as I expected, with the routine in the main program being used. I got the messages:

Linking...
lib5.lib(Source1.obj) : warning LNK4006: _SUB already defined in Console33.obj; second definition ignored
DebugConsole33.exe : warning LNK4088: image being generated due to /FORCE option; image may not run

What did you see?

[dajum]

That is the message I get, but I know that it has actually linked the one from the library. The one in the library writes to a window on the screen, but one in astap.for just returns without doing anything. My executable writes to the window. Here is the messages I get.

C:v50IVFsinda33modelsWORK>ifort @..infon.lnk
proces.lib(fwdbck.obj) : warning LNK4006: _wrstat already defined in astap.obj; second definition ignored
libifcorert.lib(libifcoremain.obj) : warning LNK4217: locally defined symbol __controlfp imported in function _testFPIEEE_RECORD
astap.exe : warning LNK4088: image being generated due to /FORCE option; image may not run

Dave

[Steven_L_Intel1]

Looking at the link map might be helpful. Otherwise, I'm out of ideas.

[dajum]

Selected lines from the .map file.

0001:00000828 _wrstat 00401828 f astap.obj

0001:000108fe _wrstat. 004118fe f proces:fwdbck.obj

THe code in astap.for

subroutine wrstat(rout,val)
character*(*) rout
real val
return
end

Now why the map was _wrstat. in it from proces confuses me. Expecially the dot after the name. Like the linker added it to the executable with an 8 character name instead of the 7 I expect. Seems if it was ignoring it, it wouldn't be included at all.

Dave

[Steven_L_Intel1]

That is odd. Do you have any ALIAS directives? Since you're using an unsupported version, there's not much else I can do.

[dajum]

This alias directive is inside of the wrstat routine in the library.

!DEC$ ATTRIBUTES DLLIMPORT,ALIAS:'_cwrstat@8' :: CWRSTAT

Its for the call to the routine in a DLL that writes to the window.

Does that help?

Dave

[Steven_L_Intel1]

Well, that will be fun. You have a STDCALL alias but have not specified /iface:cvf or /iface:stdref. Good recipe for stack corruption, unless there's something else I don't see.

Anyway, you have changed the name of CWRSTAT in the routine to be the STDCALL name, but did not (it seems) put a similar directive in the main program's version of that routine. Why DLLIMPORT inside the routine you're declaring?

[dajum]

I think you misunderstood. That Alias is for a different routine. Notice WRSTAT is the routine I'm trying to replace in the library. WRSTAT calls CWRSTAT, which has the alias as it is in a DLL.

That is the only alias around this command. But it doesn't explain to me why the compiler would say it is ignoring a library routine, and then use it. And then give it a different name in the .map file.

Dave

[Steven_L_Intel1]

Not compiler, linker. What happens if you temporarily change the name of the routine in the library and then rebuild?

[dajum]

Is that possible to do without changing the source code?

Dave

[Steven_L_Intel1]

No. I was wondering if the global name in the call from the main program didn't match that of the routine. What happens if you take your preferred routine, compile it separately, and add the object to the link?

[dajum]

I'm not sure I did what you asked. I took wrstat out of astap.for and compiled it separately. Then added that .obj name to the link list. It still gets the same duplicate name error and uses the version from the library.

One thing that may be impacting this is that that wrstat.obj doesn't exist in the library. That original routine is contained in a source file with another routine called FWDBCK. That name appears in the library (fwdbck.obj). I could remove that from the library and compile my astap.for file (also not using fwdbck) and it used the version of wrstat from inside astap.for successfully. So I wonder if the compiler gets confused by not being able to find wrstat.obj as an entity/name in the library, and when it links in fwdbck, it automatically pulls in wrstat as well.

Dave

[Steven_L_Intel1]

The compiler has little to do with this, and the names of object files are not relevant. All that matters is the global name used in the call and the one defined in the routine.

My guess is that the library defines two names for the routine - one that conflicts with your new routine and one that doesn't, and that for some reason (since I don't have a complete test case) the main program is calling the name used in the library.

Try this. Link JUST the main program source without the library. You'll get errors, but is the routine name one of them?

[dajum]

linking the main doesn't show an error for wrstat, but I guess I wouldn't expect it to since it is only called from within library routines.

Dave

[Steven_L_Intel1]

Oh, you didn't say that! (Or I missed it.) That's the way the linker works. Once the main program object is processed, it is not looked at again for references that come from later-seen objects and libraries. You might try the "force symbol reference" linker option to see if that makes a difference. You'd have to give the fully decorated global name of the routine.

[dajum]

Even more interesting. I added a new routine to the main source astap.for. It overrides a different routine in the library. In that routine I call WRSTAT. When I compile/link I still get the message that the second verison of WRSTAT is ignored. The new routine does indeed override the library version and there is no error message saying it found two. But it calls wrstat and it also gets the version from the library.

Dave

[Steven_L_Intel1]

Sorry I can't help further. This is not a compiler issue. You may want to look for an alternative solution rather than trying to override the linker.