Porting from CVF to Intel (missing dfor.lib)

Porting from CVF to Intel (missing dfor.lib)

Hi forum.

I am trying to port some projects from CVF to Intel:

Microsoft Visual Studio Professional 2012
Version 11.0.50727.1 RTMREL Version 4.5.50709

Installed Version: Professional

Visual C++ 2012   04938-004-0034007-02129
Microsoft Visual C++ 2012

Intel(R) Visual Fortran     Package ID: w_fcompxe_2013.1.119
Intel(R) Visual Fortran Composer XE 2013 Update 1 Integration for Microsoft Visual Studio* 2012, 13.0.3600.11, Copyright (C) 2002-2012 Intel Corporation

Compiling works fine now but I get link error: missing file dfor.lib. I cant find reference to this in project files?

Command Line:

/nologo /debug:full /Od /I"Debug/" /I"C:\project\project files\waxial_workspace\include" /I"C:\project\project files\waxial_workspace\src_blade\include" /I"C:\project\project files\waxial_workspace\diaphra_stress\src-files\include" /I"C:\project\project files\waxial_workspace\vaxcalc_mfc\strengthlib\Debug/" /extend_source:132 /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc110.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I suppose you have a .obj left over from the CVF build. This would require rebuilding with the current ifort, so that you aren't attempting to link against both the CVF and the ifort run-time libraries.
Note that the options /Qsave /iface:cvf are chosen to emulate some features of CVF, but it's better to work toward eliminating them in the long run, after you have resolved problems such as the one you posed.

Thanks for the Help, yes it was an old object file compiled with CVF.

Now I have another linking issue with another projects ported from CVF to IVF.

I have 2 projects both with c++ and Fortran code.

Proj 1 is building a library (Debug Multithreaded (/libs:static /threads /dbglibs)) axiallib.lib

Proj 2 is building an exe. waxcalc.exe

From proj 2 and c++ I am calling a fortran subroutine in Proj 1 (axiallib.lib)

extern "C"{void__stdcallRUN_CALCULATION_PROGRAM(); }





 and from that fortran subroutine I am calling back to Proj 2 a Fortran subroutine.





The projects 1 .lib file is incuded in Projects -> Properties -> Linker -> Input -> Additional Dependencies = ..\axiallib_mfc\axiallib.lib

The lik error tells me (building proj 2 waxcalc.exe):

>axiallib.lib(run_calculation_program.obj) : error LNK2019: unresolved external symbol _RUN_SPECIFIC_CALCULATION_PROGRAM@0 referenced in function _RUN_CALCULATION_PROGRAM

2>C:\Project\project files\waxial_workspace\Exe-filer\vaxcalc.exe : fatal error LNK1120: 1 unresolved externals


This is a major reason for recommending you build without /iface:cvf.  That option isn't compatible with current C++ default ABI.  If you are rebuilding all .obj with current compilers, removing the /iface option should take care of it.

I would agree with Tim that removing the "CVF" calling convention is advisable, but the C code you posted assumes that it is used. Whichever you pick, you have to be consistent about it.

In Visual Studio, it's on the Fortran > External Procedures property page.  Change "Calling Convention" to "Default". Then remove __stdcall from the C++ declarations of any routines called from Fortran and the Fortran routines called by C++.

Or you can make sure that the calling convention is CVF in both Fortran projects. I don't recommendt this going forward.

Steve - Intel Developer Support


Setting Calling convention to Default made the linker to stop even earlier, now the C++ extern "C"{void__stdcallRUN_CALCULATION_PROGRAM(); } could not find the fortran subroutine at all?

2> Finished searching libraries

2>vaxcalc_mfc.obj : error LNK2019: unresolved external symbol _RUN_CALCULATION_PROGRAM@0 referenced in function "public: virtual int __thiscall CVaxcalc_mfcApp::InitInstance(void)" (?InitInstance@CVaxcalc_mfcApp@@UAEHXZ)

2>vaxcalc_mfcDlg.obj : error LNK2001: unresolved external symbol _RUN_CALCULATION_PROGRAM@0

2>vaxcalc_mfc.obj : error LNK2001: unresolved external symbol _STOPFLAG

2>C:\Project\project files\waxial_workspace\Exe-filer\vaxcalc.exe : fatal error LNK1120: 2 unresolved externals

Take out the __stdcall from the C++ declarations. Look at the declaration of STOPFLAG too.  WIth the Intel default convention, STDCALL is not used.

Steve - Intel Developer Support

Thanks for Help,

But setting "Calling Convention" to "Default and removing __stdcall in declarartion im back where I started. C function finds the way to fortran sub in the .lib project but fortran sub is not finding its way back to fortran sub in 1st project.

Finished searching libraries

1>axiallib.lib(run_calculation_program.obj) : error LNK2019: unresolved external symbol _RUN_SPECIFIC_CALCULATION_PROGRAM referenced in function _RUN_CALCULATION_PROGRAM

1>C:\Project\project files\waxial_workspace\Exe-filer\vaxcalc.exe : fatal error LNK1120: 1 unresolved externals

========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========


Well, no, you're not quite back where you started.  Note that there is no @0 at the end of _RUN_SPECIFIC_CALCULATION_PROGRAM.  Did you also change the calling convention in the Fortran project(s) to Default?

Also, A Visual C++ project won't automatically link in Fortran libraries from a dependent project.  You will have to put the path to the Fortran .lib file in the C++ project as a linker "additional dependency".

Steve - Intel Developer Support

Great,  it was as you said  "add Fortran .lib file in the C++ project as a linker additional dependency" One of the lib where missing there. So dependent project only builds and not links. Thanks for the help.

It used to be that a C++ project would link in a dependent Fortran project library, but MS broke that in VS2010.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today