topic Quote:House C. wrote:I downed in Intel® oneAPI Math Kernel Library

error#7881

House_C_ — Mon, 01 Sep 2014 15:57:09 GMT

Hi,

I'm working with version XE 2013. And I use LAPACK for my project. I have done and check the following is in right setting:

1.environment variable

2. tools/options/.../complier: For include, added :\Intel\Composer XE 2013 SP1\mkl\include\ia32 . similar to lib.

3.project/properties/../linker/input. add mkl_lapack95.lib

when I rebuild the project, the software reports error#7881.

the software is win32. I have check through this forum and so far I cannot figure out any possible mistake I have make. Any one give some suggestion?

below is the whole error report:

Error 1 error #7881: This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read.

There has to be at least one

mecej4 — Mon, 01 Sep 2014 16:38:42 GMT

There has to be at least one USE statement in your program source that caused the error message to be issued. We need to know the name of the module file associated with the error message, and information on the source of the module file -- whether it was provided with the compiler, or you generated it yourself -- if so, with which compiler version and compiler options in effect?

This error message most

Steven_L_Intel1 — Tue, 02 Sep 2014 01:12:26 GMT

This error message most likely is due to building a 64-bit application but having 32-bit .mod files in the Include path. If you are building a 64-bit application, be sure to specify the 64-bit MKL modules, though you should not need to do this as it gets included automatically.

Quote:mecej4 wrote:

House_C_ — Tue, 02 Sep 2014 01:17:00 GMT

mecej4 wrote:

There has to be at least one USE statement in your program source that caused the error message to be issued. We need to know the name of the module file associated with the error message, and information on the source of the module file -- whether it was provided with the compiler, or you generated it yourself -- if so, with which compiler version and compiler options in effect?

Here is my problem: I want to use DGESV of LAPACK. In the source file of DGESV, I want to use dgetrf and dgetrs, so I state "use MKL95_LAPACK" in DGESV.f90. I failed to build the project and return the error.

My compiler is Intel Composer XE 2013 SP1, win 32.

Compiler option: listed in my previous post. project/properties/... to add the mkl_lapck95.lib; tool/options/... to add the path in libraries and include.

Below is the error message: error #7881: This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read. [MKL95_LAPACK] DGESV.f90 3

Quote:Steve Lionel (Intel)

House_C_ — Tue, 02 Sep 2014 01:49:16 GMT

Steve Lionel (Intel) wrote:

This error message most likely is due to building a 64-bit application but having 32-bit .mod files in the Include path. If you are building a 64-bit application, be sure to specify the 64-bit MKL modules, though you should not need to do this as it gets included automatically.

Hi, Steve

I have followed your instruction in other posts.I have even change the entire setting by using 64-bit mod or lib. but the same problem is there.

Quote:House C., #4 wrote:In

mecej4 — Tue, 02 Sep 2014 15:00:00 GMT

House C., #4 wrote:
In the source file of DGESV, I want to use dgetrf and dgetrs, so I state "use MKL95_LAPACK"

There is something wrong here. DGESV is a standard Lapack routine. Are you really working with the source file of the library routine (from Netlib?), or do you refer to the source code from which DGESV is being called? Saying "source file of DGESV" is causing confusion.

Secondly, DGETRF and DGETRS are Fortran-77 routines, so adding "USE MKL95_LAPACK" does nothing useful. If you are confident that you are calling DGETRF/DGETRS with the correct arguments, you do not need any USE statement -- that is the Fortran 77 way. If you want checking of the arguments, you can add include 'mkl.fi' to your source code. Likewise, you get nothing by specifying the Lapack95 libraries as linker inputs. Simply specify in your project that the MKL libraries are required.

On the other hand, using the Lapack95 interface gives you access to simpler and safer calling sequences. For example, instead of

call dgesv( n, nrhs, a, lda, ipiv, b, ldb, info )

you can issue the simpler call

call gesv( a, b [,ipiv] [,info] )

with as few as two arguments instead of the original eight arguments.

I am going to move this to

Steven_L_Intel1 — Tue, 02 Sep 2014 17:20:19 GMT

I am going to move this to the MKL forum.

Quote:mecej4 wrote:

House_C_ — Wed, 03 Sep 2014 05:11:37 GMT

mecej4 wrote:

Quote:

House C., #4 wrote:In the source file of DGESV, I want to use dgetrf and dgetrs, so I state "use MKL95_LAPACK"

There is something wrong here. DGESV is a standard Lapack routine. Are you really working with the source file of the library routine (from Netlib?), or do you refer to the source code from which DGESV is being called? Saying "source file of DGESV" is causing confusion.

Secondly, DGETRF and DGETRS are Fortran-77 routines, so adding "USE MKL95_LAPACK" does nothing useful. If you are confident that you are calling DGETRF/DGETRS with the correct arguments, you do not need any USE statement -- that is the Fortran 77 way. If you want checking of the arguments, you can add include 'mkl.fi' to your source code. Likewise, you get nothing by specifying the Lapack95 libraries as linker inputs. Simply specify in your project that the MKL libraries are required.

On the other hand, using the Lapack95 interface gives you access to simpler and safer calling sequences. For example, instead of

call dgesv( n, nrhs, a, lda, ipiv, b, ldb, info )

you can issue the simpler call

call gesv( a, b [,ipiv] [,info] )

with as few as two arguments instead of the original eight arguments.

Hi,

I downed the source code of DGESV from netlib. Following your instruction by adding include 'mkl.fi' instead of 'use' I have got the following error:

Error 1 error #6897: An interface-block in a subprogram must not contain an interface-body for a procedure defined by that subprogram. [DGESV] mkl_lapack.fi 4563

But I finally link the project by using gesv instead of dgesv. Thanks!

Quote:House C. wrote:I downed

mecej4 — Wed, 03 Sep 2014 12:13:03 GMT

House C. wrote:
I downed the source code of DGESV from netlib.

If you did that, then you would have two instances of the subroutine presented to the linker, in addition to the disallowed "interface to self" that caused the compiler to signal error #6897. You have to have a clear understanding of your intentions: do you simply want to call the Lapack routine, whether it is compiled from Netlib or other sources or linked in from MKL, or do you actually wish to do something with the internals of the source code for DGESV?

Quote:mecej4 wrote:

House_C_ — Wed, 03 Sep 2014 12:36:01 GMT

mecej4 wrote:

Quote:

House C. wrote:I downed the source code of DGESV from netlib.

If you did that, then you would have two instances of the subroutine presented to the linker, in addition to the disallowed "interface to self" that caused the compiler to signal error #6897. You have to have a clear understanding of your intentions: do you simply want to call the Lapack routine, whether it is compiled from Netlib or other sources or linked in from MKL, or do you actually wish to do something with the internals of the source code for DGESV?

I cannot agree with more for your instruction. I intended to call lapack for matrix decomposition, and I attached the DGESV source file because I cannot file the source file in mkl. As you say, DGESV is not fortran 95 language, so I use GESV instead and my problem solved. Thanks!