Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
51 Views

compiling with lapack95 routines

Hello,

I am new to using LAPACK and the MKL libraries, so please bear with me.

I am trying to compile my .f90 code with the LAPACK95 module, linking the mkl solver, core, thread and lapack95 libraries (to use LAPACK routines, and later openMP threading)

ifort /opt/intel/Compiler/11.1/069/mkl/lib/32/libmkl_solver.a /opt/intel/Compiler/11.1/069/mkl/lib/32/libmkl_core.a /opt/intel/Compiler/11.1/069/mkl/lib/32/libmkl_intel_thread.a /opt/intel/Compiler/11.1/069/mkl/lib/32/libmkl_lapack95.a -module /opt/intel/Compiler/11.1/069/mkl/include/32 filename.f90

I get the error:
error #7881: This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read. [LAPACK95]

I did the same exercise with gfortran, and the same error came up:

Fatal Error: File 'lapack95.mod' opened at (1) is not a GFORTRAN module file

Is there a way to check how the module file was compiled? I am obviously not the person who did this.

If I don't include the module file, I get these errors, which I suppose stem from not having the correct module loaded for the interface...

qsh.f90:(.text+0x1ce9): undefined reference to `getrf_'
qsh.f90:(.text+0x1cf5): undefined reference to `getri_'
qsh.f90:(.text+0x1f16): undefined reference to `getrf_'
qsh.f90:(.text+0x1f20): undefined reference to `getri_'
qsh.f90:(.text+0x2182): undefined reference to `clange_'
qsh.f90:(.text+0x2285): undefined reference to `getrf_'
qsh.f90:(.text+0x2291): undefined reference to `getri_'
qsh.f90:(.text+0x2489): undefined reference to `getrf_'
qsh.f90:(.text+0x2495): undefined reference to `getrf_'
qsh.f90:(.text+0x2683): undefined reference to `getrf_'
qsh.f90:(.text+0x268d): undefined reference to `getrf_'
qsh.f90:(.text+0x28f2): undefined reference to `clange_'
qsh.f90:(.text+0x29f5): undefined reference to `getrf_'
qsh.f90:(.text+0x2a01): undefined reference to `getrf_'
qsh.f90:(.text+0x3650): undefined reference to `sgetrf_'
qsh.f90:(.text+0x3674): undefined reference to `sgetri_'


(Following f95 interface naming convention for *tri and *trf; clange uses F77 interface)

Any tips and hits are most welcome.

Lars




0 Kudos
4 Replies
Highlighted
Black Belt
51 Views

I suppose you are picking up a .mod file built with ifort. For gfortran, you will need to remake the .mod files from the lapack95 sources, which should be present (with instructions or Makefile) in your MKL installation. Likewise, if somehow the .mod files don't match your ifort version, you can rebuild them.
Beyond that, you will need attention to the order of linking .a libraries, with the lapack library ahead of the MKL libraries which the link advisor at the top of the forum advises. The link advisor also will tell you about the linker directives for dealing with circular dependencies within MKL.
Are you using 32-bit Fortran compilers? For 64-bit compilers, you must use the MKL libraries in the /em64t/ directory. Likewise, if you want to use .mod files provided by MKL with your ifort.
0 Kudos
Highlighted
Moderator
51 Views

Lars,
my two cents in that issue - please look at the KB article describes more details about these interfaces libraries "Blas and Lapack Fortran 95 mod files"
0 Kudos
Highlighted
Beginner
51 Views

I looked at the mod file document and the linker advisor tool, and corrected my mistakes. I tried:

ifort -o qsh -Wl,--start-group $MKLroot/libmkl_intel_ilp64.a $MKLroot/libmkl_sequential.a $MKLroot/libmkl_core.a -Wl,--end-group -lpthread -module /opt/intel/Compiler/11.1/069/mkl/include/em64t/ilp64/ qsh.f90

I get the error messages " There is no matching specific subroutine for this generic subroutine call. [GETRI]
CALL GETRI(G0,PIVOT_LX)"

for all my calls to getri using f95 notation (just a matrix argument). It does not complain about getrf.

When I use F77 routines instead of f95, I get the errors
qsh.f90:(.text+0x1d1b): undefined reference to `cgetrf_'
qsh.f90:(.text+0x1d3f): undefined reference to `cgetri_'
qsh.f90:(.text+0x1f6f): undefined reference to `cgetrf_'
qsh.f90:(.text+0x1f91): undefined reference to `cgetri_'
qsh.f90:(.text+0x21d2): undefined reference to `clange_'
qsh.f90:(.text+0x22db): undefined reference to `cgetrf_'
qsh.f90:(.text+0x22ff): undefined reference to `cgetri_'
qsh.f90:(.text+0x250b): undefined reference to `cgetrf_'
qsh.f90:(.text+0x252f): undefined reference to `cgetri_'
qsh.f90:(.text+0x272c): undefined reference to `cgetrf_'
qsh.f90:(.text+0x274e): undefined reference to `cgetri_'
qsh.f90:(.text+0x2992): undefined reference to `clange_'
qsh.f90:(.text+0x2a9b): undefined reference to `cgetrf_'
qsh.f90:(.text+0x2abf): undefined reference to `cgetri_'
qsh.f90:(.text+0x369f): undefined reference to `cgetrf_'
qsh.f90:(.text+0x36c3): undefined reference to `cgetri_'

So obviously something is still wrong. The processor is Intel Xeon CPU 2.80GHz, and I am on a 64 bit linux system (x86_64 GNU/Linux).

0 Kudos
Highlighted
Black Belt
51 Views

Linux linker is order-dependent. This is the reason for the start-group end-group directives to rescan that group. Still, the libraries must come after your sources.
I'm a little surprised that you selected ilp64, meaning that you have changed all the integers in your MKL function calls to 64-bit types (integer(kind=8)). That won't affect the undefined references, but a discrepancy there would lead to run-time failure.
0 Kudos