- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am going to move this to the MKL forum.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page