Problems linking with mkl95 libraries

[acar]

Hi, I would like to use the f95 interfaces to the lapack linear algebra routines. I have successfully got the sparse solver pardiso to run but cannot seem to do so with the routine getrf.

In the subroutine that calls getrf I have the two use statements mkl95_precision and mkl95_lapack.

I have made the suggested mofifications to the project properties but get the following linker error message:

error LNK2019: unresolved external symbol _DGETRF_MKL95@12 ...

Any advice on solving this would be much appreceated.

Thanks,

ACAR

[TimP]

Guessing that you are using an ifort compatible version of MKL, it seems wrong to expect support for /iface:cvf or the like. Beyond that, I can't guess what properties you have set.
If you are using CVF, you would probably have to rebuilt the blas95/lapack95 libraries with it.

[acar]

Quoting - tim18

Guessing that you are using an ifort compatible version of MKL, it seems wrong to expect support for /iface:cvf or the like. Beyond that, I can't guess what properties you have set.
If you are using CVF, you would probably have to rebuilt the blas95/lapack95 libraries with it.

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

[Steven_L_Intel1]

MKL has its own forum section where the MKL experts hang out - I'll move this there.

[TimP]

Besides assuring that you didn't set /iface:cvf (e.g. by some conversion of a CVF project), you will need the lapack95 library in your dependencies. Most questions about MKL are dealt with on that forum.
2nd attempt to post reply

[acar]

Quoting - tim18

Besides assuring that you didn't set /iface:cvf (e.g. by some conversion of a CVF project), you will need the lapack95 library in your dependencies. Most questions about MKL are dealt with on that forum.
2nd attempt to post reply

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_M_Intel]

Quoting - 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

Why are you using iface:stdcall? That's the actual cause of your problems with character string dummy arguments. Is it to be compatible with routines from another existing library you'd created with CVF?

Also, which version of IVF are you using?

thanks --

- Lorri

[Gennady_F_Intel]

Quoting - acar

Quoting - tim18

Guessing that you are using an ifort compatible version of MKL, it seems wrong to expect support for /iface:cvf or the like. Beyond that, I can't guess what properties you have set.
If you are using CVF, you would probably have to rebuilt the blas95/lapack95 libraries with it.

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

ACAR,
please look at the topic. You can find there the mvsc project attached. may be it will usefull for you.
--Gennady

[Gennady_F_Intel]

Quoting - 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:

ACAR,
what is your linking line? Please look at the mkl's userguide how to link with Interface libraries.
--Gennady

[acar]

Quoting - Lorri Menard (Intel)

Why are you using iface:stdcall? That's the actual cause of your problems with character string dummy arguments. Is it to be compatible with routines from another existing library you'd created with CVF?

Also, which version of IVF are you using?

thanks --

- Lorri

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

[acar]

Quoting - Gennady Fedorov (Intel)

ACAR,
what is your linking line? Please look at the mkl's userguide how to link with Interface libraries.
--Gennady

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.1�51mklia32lib" /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

[Gennady_F_Intel]

Quoting - 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.1�51mklia32lib" /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

ACAR,
for using the stdcall interface, link with mkl_intel_s.lib. The dynamic counterparts of these interface libraries are mkl_intel_c_dll.lib and mkl_intel_s_dll.lib.
--Gennady

[Artem_V_Intel]

Quoting - 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.1�51mklia32lib" /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

Hello ACAR,

The threading layer library has been missed in your latest link line. It should be mkl_intel_thread.lib for threaded implementation or mkl_sequential.lib for sequential implementation of MKL routines. Finally the link line should be like that:

mkl_lapack95.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libiomp5md.lib for threaded implementation

and like that:

mkl_lapack95.lib mkl_intel_c_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib for sequential implementation.

Thanks,
Art

[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.

[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