LNK1104: cannot open file 'ifconsol.lib'

[cmundi]

I am doing mixed-language (C++ calls Fortran) development using IVF 10.0.26 and MSVC8 under DevStudio 2005.

I am building a C++ Windows Console application, which needs to link with a static Fortran library. The Fortran .lib file is built, no problem. The C++ code compiles but does not link. I have confirmed that I can build a C++ Windows COnsole "hello world" program with no problem. In fact, my own C++ code builds fine if I comment out the call to the Fortran lib. Of course, I want to call Fortran. :)

I have added the path and name of my Fortran lib to the linker options, so that the command line includes the explicit Fortran lib and its corresponding /LIBPATH. No joy.

If I try to add ifconsol.lib explicitly, I get all kinds of errors of course.

Here is the relevant snippet of output from the linker with /verbose:

Processed /DEFAULTLIB:kernel32.lib
2> Processed /DISALLOWLIB:libc.lib
2> Processed /DISALLOWLIB:libcd.lib
2> Processed /DISALLOWLIB:libcmt.lib
2> Processed /DISALLOWLIB:msvcrt.lib

... lots of linkages found...

2> Searching C:Program FilesMicrosoft Visual Studio 8VClibOLDNAMES.lib:
2>LINK : fatal error LNK1104: cannot open file 'ifconsol.lib'

Again, this happens only if I actually try to call a routine in my Fortran library.

Finally, I have tried several of variations of calling conventions, including /iface:cvf. It doesn't matter. So I seem to not be getting far enough (like runtime!) to see how badly messed up my calling conventions may be.

I am very puzzled that linking to an external lib would exercise ifconsol.lib, since I thought that was particular to the QuickWIn subsystem.

I am in serious need of a clue, please.

[cmundi]

Ok, my first clue came in the form of realizing that maybe my C++ project does not know where to find the IVF libs and so when the C++ links in the Fortran and the Fortran tries to link the IVF libs... bad news. So I went ahead and added

C:Program FilesIntelCompilerFortran10.0.026IA32Lib

and

C:Program FilesIntelCompilerFortran10.0.026IA32Include

to the VC++ Directories under Tools...Options in DevStudio 2005.

The LNK1104 is gone, but I have a new problem!

When linking my C++ code, the linker complains that it cannot resolve the following:

2>Finished searching libraries
2>Finished pass 1
2>Generating non-SAFESEH image.
2>Invoking CVTRES.EXE:
2> /machine:x86
2> /verbose
2> /out:"C:DOCUME~1cmundiLOCALS~1Templnk4E52.tmp"
2> /readonly
2> ".DebugInteroperate.exe.embed.manifest.res"
2>Microsoft Windows Resource To Object Converter Version 8.00.50727.42
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>adding resource. type:MANIFEST, name:1, language:0x0409, flags:0x30, size:2048
2>FortranLib.lib(GetValue.obj) : error LNK2019: unresolved external symbol _for_emit_diagnostic referenced in function _cleanup
2>FortranLib.lib(GetValue.obj) : error LNK2019: unresolved external symbol _for_cpystr referenced in function _cleanup
2>FortranLib.lib(GetValue.obj) : error LNK2019: unresolved external symbol _for_len_trim referenced in function _GetValue
2>C:Documents and SettingscmundiMy DocumentsVisual Studio 2005ProjectsInteroperateDebugInteroperate.exe : fatal error LNK1120: 3 unresolved externals
2>Build log was saved at "file://c:Documents and SettingscmundiMy DocumentsVisual Studio 2005ProjectsInteroperateInteroperateDebugBuildLog.htm"
2>Interoperate - 4 error(s), 0 warning(s)
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Surely I am very close now... ideas?

Thanks!

[cmundi]

I fogot to mention that cleanup and GetValue are (the only) symbols in my Fortran library, FortranLib.lib. But you figured that out already...

[Jugoslav_Dujic]

"When everything fails, read the documentation"

The case is explained in Intel documentation, in the page titled "Building Intel Fortran/C Mixed-Language Programs on Windows* Systems". In short, you have to ensure that you supply ifconsol.lib and an appropriate libifcore*.lib to the linker (as well as the path to Intel Fortran run-time libraries, commonly C:Program FilesIntelCompilerFortran10.0.025IA32Lib).

[cmundi]

Mixed-language development is always a little sticky, and the docs going back to CVF, DEC and MS all testify to that. Intel has improved the docs in this area somewhat, but there is no getting around the fact that it's a mess. Thankfully, it's one that Intel is taking head-on.

But I could have read all the docs for a 10th time and not found a solution today. I got the bits about making the IVF libs accessible and not disabling the default lib search rules for IVF; that was all obvious enough. The real culprit turned out to be that DevStudio2005 selected the MD runtime libs instead of the MT runtime libs for the C++ main(). This is probably a reasonable choice -- unless you've already told DevStudio that you're linking with a Fortran static lib...

These lib mismatches have bitten me before, and every time I wonder why I don't see the signs. Even with /verbose on everywhere, I didn't get much in the way of clues. That's a gripe for Microsoft, not Intel. IVF is doing exactly what I need.

[Steven_L_Intel1]

I would not expect a library type mismatch to result in an error about being unable to open a library. Instead, one usually gets undefined or duplicate symbol errors.

[cmundi]

Steve,

That's what threw me at first. Anyway, I eventually got it sorted out for IVF and DevStudio2005. Thanks to you smart guys at Intel for making this relatively painless.

FYI, my approach is to tweak the ATTRIBUTES on the F90 side, so that I can use ordinary C-linkage on the C-side. In other words, I don't use __stdcall on the C-side.

Now I have to backport (shudder) what I've learned to a separate but related product using CVF at a customer site. Already, I see that there might be differences in the ATTRIBUTES that I will need to use. I know it's off-topic, but is it permissible to post about this here?

Thanks!

[Steven_L_Intel1]

The major difference you'll find with CVF is that it defaults to STDCALL - note that Intel Fortran does not unless you tell it to (/iface:cvf, /iface:stdref, STDCALL attribute). You can ask about CVF here.