LNK2019

[Rob1]

I am trying to use the NRM2 function in blas.

The subroutine i am using it in i have "USE BLAS95".

I have Properties>Linker>General>Additional Library Directories>C:\\Program Files (x86)\\Intel\\Compiler\\11.1\\067\\mkl\\include\\ia32 which is where the precompiled .mod files are.

When i compile i get:

Error 1 error LNK2019: unresolved external symbol _DNRM2_F95 referenced in function _CALCF calcF.obj

I assume i need to link some lib file(s) also?

How do i do that when building from within VS2008?

Any help is greatly appreciated.

rob

[mecej4]

Project=>Properties=>Fortran=>Libraries=>Use Intel MKL {make your selection}
Project=>Properties=>Linker=> Additional Dependencies mkl_blas95.lib

[Rob1]

That makes it compile without errors, thanks!

However, i get the following error immediately when I run the program (this error is new since adding MKL):

"The application was unable to start correctly (0xc000007b)."

My OS is win7 64.

Intel fortran 11.1.067.

The solution platform is Win32 in VS2008.

UnderProject=>Properties=>Fortran=>Libraries=>Use Intel MKL i tried parallel, sequential, and cluster. Cluster will not compile, parallel and sequential compile but i get the above error.

thanks.

[mecej4]

You may have some inconsistencies in your VisualStudio setup or project settings.

Do you have both 32 and 64 bits of Intel Fortran installed? Did you build the application for WIn-32 or Win-64?

See if this article helps.

[Rob1]

Thank you very much for the help.

Is there a way to tell if i have 32/64/both? I don't recall what was installed.

I am building the application for win32 (build>configuration manager>platform>win32).

_

I tried building a simple program that uses a function from BLAS:

_

------------------------

PROGRAM main

USE blas95

IMPLICIT NONE

REAL*8 ans

ans = NRM2([1.d0,1.d0,1.d0])

write(*,*) ans

read(*,*)

STOP

ENDPROGRAM

------------------------

_

I have the following settings:

project>properties>fortran>use intel math kernal library>sequential

project>properties>linker>input>additional dependencies>mkl_blas95.lib

_

I am also including in this project blas.f90 (a total of 2 files, main.f90 and blas.f90) or else it won't build. Is this correct?

_

When i run the above program it works fine. However when i open this exe in dependency walker i get this:

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.

Error: Modules with different CPU types were found.

Warning: At least one delay-load dependency module was not found.

Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

IESHIMS.DLL Error opening file. The system cannot find the file specified(2).

_

_

_

When i build a new project, all default settings, with an empty main program file:

PROGRAM main

IMPLICIT NONE

STOP

ENDPROGRAM

I get the exact same errors and warnings as above in dependency walker.

In the dependency walker tree, my compiled executable "test.exe" is 32bit, but every single dll (1000's of them?) are 64bit.

_

_

When i open my original program in dependency walker, i get the same errors with the addition of:

Error: At least one required implicit or forwarded dependency was not found.

MSVCR80.DLL Error opening file. The system cannot find the file specified(2).

_

I still am getting the same error as in my previous post but like you said there seems to be a conflict in my build somewhere?

[mecej4]

Please post the build log from a successful build of your program in VisualStudio.

[Rob1]

build log should be attached.

thanks,

rob

[mecej4]

I don't see any problems in the build log file. The project appears to have been built using only 32-bit objects.

When you run the EXE from the command line, what environment do you use? Do you use a default command window, or one with the proper environment for Intel Fortran?

Is is feasible to attach one of the EXEs that builds correctly but aborts with the 0xC000007b exception?

[Rob1]

I have been running the program from VS2008 in debug mode.

I get the same error when run from a default command window or if launched from within windows.

Attached is the EXE that corresponds to the build log from my previous post.

When i run this exe i get the 0xc000007b error.

[mecej4]

Your MAIN.EXE needs to load the 32-bit Matlab DLLs LIBMX.DLL and LIBMAT.DLL, the MKL DLLs, the IFort runtime DLLS and MSVC DLLs.

When running from the command line, you should have all these DLLs available in the execution path. If some of them are not accessible, or you have a 64 bit version of Matlab, you will encounter errors.

On my 32-bit Windows XP your program MAIN.EXE ran and gave the output:

Error opening psave.mat

Make sure the LTS setups directory and files do not contain spaces or funny characters,

and is located in the correct directory within the current setups directory.

Press enter to close...

[Rob1]

Yeah this is where i am unsure.

I have the correct 32bit matlab dll's included with the final build, that's all good.

I apologize for these probably obvious questions but...

.

My question is with:

c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_50916076bcb9a742\MSVCR90.DLL

c:\program files (x86)\intel\compiler\11.1\067\lib\intel64\LIBIFCOREMDD.DLL

c:\program files (x86)\intel\compiler\11.1\067\lib\intel64\LIBIFPORTMD.DLL

c:\program files (x86)\intel\compiler\11.1\067\lib\intel64\LIBMMDD.DLL

c:\program files (x86)\intel\compiler\11.1\067\mkl\em64t\bin\MKL_SEQUENTIAL.DLL

c:\windows\system32\KERNEL32.DLL

.

TheMSVCR90.DLL is 32bit, however the rest are 64bit according to dependency walker. I'm not sure if this is a problem?

.

I'm not sure about the "IFort runtime DLLs", do i need to referencethe following 3? (these were taken from dependency walker, do I need the files out of the respective 32 bit directory?):

c:\program files (x86)\intel\compiler\11.1\067\lib\intel64\LIBIFCOREMDD.DLL

c:\program files (x86)\intel\compiler\11.1\067\lib\intel64\LIBMMD.DLL

c:\program files (x86)\intel\compiler\11.1\067\lib\intel64\LIBIFPORTMD.DLL

.

As far as the "MSVC DLLs" are you just talking about MSVCR90.DLL and MSVCRT.DLL? I guess i have been assuming these dlls are registered on the users' computers. I can see how it would be a problem if they weren't however.

.

For the MKL DLLs:

c:\program files (x86)\intel\compiler\11.1\067\mkl\em64t\bin\MKL_SEQUENTIAL.DLL

c:\program files (x86)\intel\compiler\11.1\067\mkl\em64t\bin\MKL_CORE.DLL

Again, i don't understand why it is referencing files out of the 64 bit directory.

.

Thanks again for all your help!

rob

[mecej4]

I believe that the problem is with your PATH environment variable.

Dependency Walker reports the first instance of a DLL by searching along %PATH%. If it finds a 64-bit DLL first, that is the one that it reports. This is something that I established by opening two command windows in Win7 X64, one for IFort-32 and another for IFort-64. From each command window, I called Dependency Walker to open a single 32-bit EXE (your MAIN.EXE). The first instance showed only 32-bit DLLs, and the second showed only 64-bit DLLs.

The standard installation of Intel Fortran configures shortcuts to CMD.EXE with the environment variables suited to the target (32-bit or 64-bit). If the batch file that is run to set up one of these sessions has been corrupted, problems of the type that you reported will arise.

[Rob1]

Yeah that makes sense.

I actually got it to run by moving the following DLLs into the executable directory:

libifcoremdd.dll

libifportmd.dll

libmmd.dll

libmmdd.dll

mkl_core.dll

mkl_def.dll

mkl_sequential.dll

msvcr80.dll

zlib1.dll

I had to use a combination of dependency walker and command line execution in order to find out which DLLs were needed. There must be an easier way.

Here is my path variable:

C:\Program Files (x86)\Intel\Compiler\11.1\067\lib\intel64;

C:\Program Files (x86)\Intel\Compiler\11.1\067\lib\ia32;

c:\program files (x86)\intel\compiler\11.1\067\mkl\em64t\bin;

C:\Program Files\Common Files\microsoft shared\windows live;

C:\Windows\system32;

C:\Windows;

C:\Windows\system32\wbem;

C:\Windows\system32\windowspowershell\v1.0\;

c:\program files\intel\dmix;

c:\program files\intel\wifi\bin\;

c:\program files\common files\intel\wirelesscommon\;

c:\program files\widcomm\bluetooth software\;

c:\program files\widcomm\bluetooth software\syswow64;

c:\program files (x86)\ntru cryptosystems\ntru tcg software stack\bin\;

c:\program files\ntru cryptosystems\ntru tcg software stack\bin\;

c:\program files\wave systems corp\gemalto\access client\v5\;

c:\program files (x86)\microsoft sql server\90\tools\binn\;

c:\program files (x86)\quicktime\qtsystem\;

C:\Program Files (x86)\MATLAB\R2010b\bin\win32;

C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;

C:\mingw\bin;

_

So i understand now why it was finding the 64 bit files. I suppose i will remove the intel 64 directories (from path) for the future.

Dependency walker still gives the "modules with different cpu types" error. The only 64 bit DLLs listed in dependency walker are the windows ones (KERNEL32.DLL, NTDLL.DLL, etc.). I assume this is ok?

It works now so i guess that is all that matters.

Again thank you very much for helping me on this non-mkl related issue.

rob

[mecej4]

Experiences with such problems lead one to reject the software installer's offer to change the environment. I work with several different compilers, and my set up will not tolerate an installer messing up the environment for compilers other than the one it is installing.

[TimP]

When I was involved with the Intel Cluster Ready project, a requirement was that neither Intel's nor anyone else's software installation would make persistent changes in the environment; each Intel tool had to be set up by sourceing the corresponding environment script when required. This requirement had to be satisfied also by 3rd party applications which were certified under ICR. Needless to say, ICR didn't achieve the hoped for market acceptance.