Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

error#7881

House_C_
Beginner
1,978 Views

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.

0 Kudos
1 Solution
mecej4
Honored Contributor III
1,978 Views

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 dgesvnnrhsaldaipivbldbinfo )

you can issue the simpler call

     call gesvab [,ipiv[,info] )

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

View solution in original post

0 Kudos
9 Replies
mecej4
Honored Contributor III
1,978 Views

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?

0 Kudos
Steven_L_Intel1
Employee
1,978 Views

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.

0 Kudos
House_C_
Beginner
1,978 Views

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    

 

0 Kudos
House_C_
Beginner
1,978 Views

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. 

 

0 Kudos
mecej4
Honored Contributor III
1,979 Views

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 dgesvnnrhsaldaipivbldbinfo )

you can issue the simpler call

     call gesvab [,ipiv[,info] )

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

0 Kudos
Steven_L_Intel1
Employee
1,978 Views

I am going to move this to the MKL forum.

0 Kudos
House_C_
Beginner
1,978 Views

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 'useI 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!

0 Kudos
mecej4
Honored Contributor III
1,978 Views

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?

0 Kudos
House_C_
Beginner
1,978 Views

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! 

0 Kudos
Reply