Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Rob1
Beginner
76 Views

LNK2019

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
0 Kudos
14 Replies
mecej4
Black Belt
76 Views

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

Rob1
Beginner
76 Views

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
Black Belt
76 Views

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
Beginner
76 Views

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
Black Belt
76 Views

Please post the build log from a successful build of your program in VisualStudio.
Rob1
Beginner
76 Views

build log should be attached.
thanks,
rob
mecej4
Black Belt
76 Views

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
Beginner
76 Views

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
Black Belt
76 Views

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
Beginner
76 Views

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
Black Belt
76 Views

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
Beginner
76 Views

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
Black Belt
76 Views

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
Black Belt
76 Views

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.