MKL95_LaPACK does not compile with Intel Fortran 10.1.014

[salmanansari]

I am compiling MKL libraries (particularly MKL95_LaPACK) with Intel Fortran and get the error shown below.

I am including in the paths following directories:

%INTEL MKL DIRECTORY%include
%INTEL MKL DIRECTORY%ia32lib

and I am calling the libraries

mkl_c.lib libguide.lib mkl_lapack95.lib

I upgraded ifort from 10.1.013 to 10.1.014 to see if it was a compiler issue but the problem persists. It used to work okay with MKL 9.1 but I can't remember with which version of ifort.

Any clues? Please help.

Compiling with Intel Fortran Compiler 10.1.014 [IA-32]...
ifort /nologo /Zi /Od /include:&quotE:fortranvstudioeniaInclude" /include:&quotD:Program FilesIntelMKL10.0.1.015ia32lib" /include:&quotD:Program FilesIntelMKL10.0.1.015include" /gen-interfaces /warn:interfaces /module:&quotDebug" /object:&quotDebug" /traceback /check:bounds /libs:static /threads /dbglibs /c /Qvc8 /Qlocation,link,&quotD:Program FilesMicrosoft Visual Studio 8VCin" &quotE:fortranvstudioeniaSourcemain.f90"
Linking...
Link /OUT:&quotDebugenia.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:&quotD:Program FilesIntelMKL10.0.1.015ia32lib" /MANIFEST /MANIFESTFILE:&quotE:fortranvstudioeniadebugzenia.exe.intermediate.manifest" /DEBUG /PDB:&quotE:fortranvstudioeniadebugzenia.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:&quotE:fortranvstudioeniadebugzenia.lib" mkl_c.lib libguide.lib mkl_lapack95.lib /fixed:no &quotDebugplanforms.obj" &quotDebugkinematics.obj" &quotDebug ypes.obj" &quotDebugparameters.obj" &quotDebuginit.obj" &quotDebugmath.obj" &quotDebugfiler.obj" &quotDebugzenia.obj" &quotDebugmain.obj"
backend signals

Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3)
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3)


Zenia - 2 error(s), 0 warning(s)

[Steven_L_Intel1]

Please report this to Intel Premier Support.and attach a ZIP of your Visual Studio project.

[TimP]

Even if you haven't read the instructions about the changes in linking required for MKL 10, that failure is a compiler bug, which should be reported against ifort, if you are willing to submit a case which reproduces it. That might also help the support teams consider improvements in documentation.
The fact that the compiler link script has gone off into IPO even though you set /Od is a bad sign.
The instructions warn against static linking, particularly where it could result in linking against both a static and a dynamic OpenMP library. I think that implies that backward compatibility static linking (not changing your choice of .lib designations to conform with MKL 10) is a bad idea.
You probably should be linking mkl_core.lib (or the dynamic one) and your choice of the thread or sequential libraries.
If you are using the threaded library, you might consider avoiding the OpenMP library which comes with MKL and setting the ifort option /Qopenmp so that ifort provides that library.
As you are using VC8 tools, there is no need to shift to the VC9 compatible OpenMP libraries.

[salmanansari]

Thanks for that Steve.

I have submitted it to Intel Premier Support as you suggest. Their first suggestion was try and compile it with MKL 9.1 and I found that it works okay. The error appears to come as soon as I add mkl_c.lib to the list of libraries in MKL 10.1.

Bizarre?

Thanks!

Salman

[salmanansari]

And thanks for that Tim.

I have tried compiling with mkl_core.lib but the problem changes to

1>Linking...
1>mkl_lapack95.lib(sgelsy.obj) : error LNK2019: unresolved external symbol _SGELSY referenced in function _SGELSY_MKL95
1>mkl_lapack95.lib(sgelsy.obj) : error LNK2019: unresolved external symbol _XERBLA referenced in function _SGELSY_MKL95
1>Debugenia.exe : fatal error LNK1120: 2 unresolved externals

as if it is not compiling the MKL_LaPACK95 library. Also tried with the sequential library mkl_sequential.lib but to no avail. Perhaps, I am doing something wrong.

Which libraries would you suggest to link with to use MKL_LaPACK95, please?

Thanks!

Salman

[g_f_thomas]

Was this issue ever resolved?

On the MKL forum I just posted this after several days of trying to find from those in the know as to why the MKL_LAPACK95 interface bombs big time whereas the f77 doesn't. Looks to me that closerliaison between IVF and MKL is in order.

Why is the MKL77_LAPACK module missing from MKL 10.0.1.015?

Is it also missing from MKL 10.0.2.019?

Little wonder that the so called MKL_LAPACK95 interface crashes on use: a search through the source folder reveals that of 937 files there some 380 of them require MKL77_LAPACK.

Gerry

[Steven_L_Intel1]

I'm not an MKL expert, but I don't think MKL77_LAPACK missing is a problem.

When you build the lapack95 interfaces, as described in the documentation, it compiles interfaceslapack95sourcesmkl_lapack_protos.f90. This defines module MKL77_LAPACK.This module is used when the LAPACK95 modules are compiled but is not needed afterward and is deleted. I can't find any documentation suggesting that your code should be using MKL77_LAPACK (F77 code doesn't know modules).

I ran the makefile to build the lapack95 samples after building the interfaces and it all worked.

What exactly is the problem? I'm not saying there isn't one, but I don't understand the issue yet.

[g_f_thomas]

I agree, MKL77_LAPACK is defined by mkl_lapack_protos.f90. Who would have thought so? I didn't go through the makefile as I don't recall creating the lapack95 interface although it is where its supposed to be. As far as I can remember the only interface I built was blas95. In any event, with use of the f95 interface I land up in the CRT dbheap trying to validate dangling pointers which fail whereupon an Access Violation occurs.

Monday I'll install the recent updates to IVF and MKL with running the lapack95 makefile as the first thing to do.

Thanks for the help, much appreciated.

Gerry

[Steven_L_Intel1]

I recently worked a customer issue where the program used both the blas95 and lapack95 interfaces. As stated in the MKL documentation, you must build the modules after installation as MKL supports use from non-Intel compilers, so it doesn't provide precompiled modules. I had no problem using these interfaces in the customer program. Also, when I run the lapack95 samples makefile, it builds and runs several dozen example programs, and there were no errors.

If there is a problem, we'd like to know about it.

[g_f_thomas]

I've installed the latest IVF and MKL. When I run nmake to generate the blas95 or lapack95 interface I get a message:

'ifort' not recognized as internal or external command

There is an environment variable FC=IFORT, and both IVF and MKL are in the PATH. How can I get nmake to do what its supposed to do?

Thanks,

Gerry

[brianlamm]

Gerry,

I skirt the whole issue and do this (this is for a few functionsI need from MKL BLAS:

INCLUDE 'mkl_blas_protos.f90'
!
MODULE mod_BLAS_realcplx_int
PRIVATE
PUBLIC :: DOT, GEMV, NRM2,
!
! import BLAS through Intel MKL ( MKL-specific )
! NOTE: updated to MKL Fortran 95 interfaces 12/05/2005
!
INTERFACE DOT
MODULE PROCEDURE SDOT_MKL95, DDOT_MKL95
END INTERFACE DOT
!
INTERFACE GEMV
MODULE PROCEDURE SGEMV_MKL95, DGEMV_MKL95, &
CGEMV_MKL95, ZGEMV_MKL95
END INTERFACE GEMV
!
INTERFACE NRM2
MODULE PROCEDURE SNRM2_MKL95, DNRM2_MKL95, &
SCNRM2_MKL95, DZNRM2_MKL95
END INTERFACE NRM2
!
CONTAINS
!
INCLUDE 'sdot.f90'
INCLUDE 'ddot.f90'
!
INCLUDE 'sgemv.f90'
INCLUDE 'dgemv.f90'
INCLUDE 'cgemv.f90'
INCLUDE 'zgemv.f90'
!
INCLUDE 'snrm2.f90'
INCLUDE 'dnrm2.f90'
INCLUDE 'scnrm2.f90'
INCLUDE 'dznrm2.f90'
!
END MODULE mod_BLAS_realcplx_int

I add to the include option on command ifort the directory

interfaceslas95source to find all the above written INCLUDES.

This has been working for me for a long time now.

-Brian

[Steven_L_Intel1]

Gerry, it sounds as if you did not open a "Fortran build environment" command window. This runs the compiler's Binifortvars.bat script to add ifort properly to the path. I don't know how you defined the path.

I've built the lapack95 and blas95 files multiple times - just open a build environment prompt, CD to the proper folder and do "nmake lib32" or whatever.

[g_f_thomas]

Thanks Steve, that got the ball rolling.

Gerry

[g_f_thomas]

Thanks Brian, that's handy to know.

Gerry