Just purchased latest IVF which has MKL bundled with it - so I hope I'm in the right place for support. I haven't rebuilt the libraries as it is the native compiler that I'm using.

I've just tried to simplify matters by opening up a new project and adding one of the intel example files for lapack95 - gbsv.f90. I've added ...mklincludeia32 to the fortran>general>additional include directories list. I've switched fortran>preprocessor>preprocess source file to yes. I've added ...mklia32lib to linker>general>additional library directories. I've added mkl_intel_c.lib, mkl_intel_thread.lib, mkl_core.lib and libiomp5md.lib to linker>input>additional dependencies. I get the same problem:

error lnk2019 unresolved external symbol _sgbsv_mkl95 ...

Any help would be appreceated.

Thanks,

ACAR

Okay problem solved for the new project by explicitly adding mkl_lapck95.lib to the linker>general>additional dependencies list as suggested by tim18 - many thanks tim. Also now recognise that there is another forum for mkl issues. For my actual application, which was a conversion from cvf, iface was set to cvf. I have now switched it to stdcall, added mkl_lapack95.lib to the additional dependencies (as above) and although the original linker error has now been resolved I am getting a large number of linker errors lnk2001 and lnk2019 which are refering to routines which pass character variables to a routine which uses character(*)::text in the declaration, i.e. the string length is variable. e.g:

program main

real(8)::rval
integer::ival
character(20)::boris(2)
integer::jval

rval=10d0
ival=1
boris(1)='a good chap'
boris(2)='a bad chap'
jval=2

call sub(rval,ival,boris(1),boris(2),jval)

end program main

subroutine sub(rval,ival,boris1,boris2,jval)

real(8)::rval
integer::ival
character(*)::boris1
character(*)::boris2
integer::jval

end subroutine sub

Maybe I was doing something illegal or irregular in cvf but this sort of setup worked fine.

I'd be grateful for any advice on this matter - which maybe that I simply need to fix the length of character strings and/or explicitly pass the length.

Many thanks,

ACAR

Lorri,

My application was a conversion from cvf to the latest version of ivf. It converted reasonably well with only a few modifications required to get going again. Since then, however, I have needed to replace some imsl linear algebra calls with equivalent mkl routines and hence the current issues. Another respondent to my post suggested I check the iface option and indeed it was set to cvf presumably from when I ran the original conversion. I tried default which produced 1000s of linker errors and didn't seem to solve the mkl link error so I opted for stdcall which produced rather less errors.

Thanks for your interest and any assistance would be helpful.

ACAR

Thanks Gennady. I had previously looked at the thread you suggested and tested out one of the examples provided with the compiler and did manage to get it working. Applied the same operations to my application without success. I have been studying the mkl userguide rather intensively but unless I'm missing a crutial point then I have done all it suggests. I am compiling and linking from within the vs developer environment and so the linker options are being set by the project properties dialog. The command line is:

/OUT:"Debug/EFESYS.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:Program FilesIntelCompiler11.151mklia32lib" /NODEFAULTLIB:"dfconsol.lib" /MANIFEST /MANIFESTFILE:"C:RMAProgramsEFE_V1.1EFEDebugEFESYS.exe.intermediate.manifest" /DEBUG /PDB:"Debug/EFESYS.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"WinMainCRTStartup" kernel32.lib mkl_solver.lib mkl_intel_c_dll.lib mkl_core_dll.lib mkl_blas95.lib mkl_lapack95.lib

Thanks,

ACAR

Hi Gennady,

I have been out of action for a few days hence the delay in responding. I am still having problems with linking in the libraries. I downloaded the example file 70693, changed the paths in project settingsto reflect the that my ivf release is slightly later than the one this project was written for and the project compiled and linked. However if I changed iface to cvf it failed to link with lnk2019 unresolved external symbol _sgesv_mkl95@16. So this is mirroring the problem I have with my project which was originally a cvf project and brings up errors as described if I change iface.

I really need to solve this problem and would be grateful for any help/advice that you or anyone else is able to give....

Many thanks for everyones' time.

ACAR.

Hi All,

I have managed to get the project to compile and link with the default calling convention and the following link line:

/OUT:"Debug/EFESYS.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\Intel\Compiler\11.1\051\mkl\ia32\lib" /NODEFAULTLIB:"dfconsol.lib" /MANIFEST /MANIFESTFILE:"C:\RMA\Programs\EFE_V1.1\EFE\Debug\EFESYS.exe.intermediate.manifest" /DEBUG /PDB:"Debug/EFESYS.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"WinMainCRTStartup" mkl_lapack95.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib

Thanks for your help.

ACAR