- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greetings,
I'm trying to compile and link a use-subroutine for a commercial FE code. In my code, I have following lapack calls:
use lapack95 call potrf(cmMinusCfInv) call potri(cmMinusCfInv)
To compile, I use /Qmkl among a bunch of other compiler directives and it compiles without complaining about use lapack95.
To link as dll, I used Intel® Math Kernel Library Link Line Advisor and according to that, calling:
mkl_blas95_lp64.lib mkl_lapack95_lp64.lib mkl_intel_lp64_dll.lib mkl_core_dll.lib mkl_intel_thread_dll.lib
in the link line. Then the Liker gives following error:
error LNK2019: unresolved external symbol dpotrf_f95 referenced in function ...
The folder that includes mkl libraries are added to the lib path:
export LIB="C:\\Program Files (x86)\\Intel\\Composer XE 2013 SP1\\compiler\\lib\\intel64;C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE;C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\ATLMFC\\LIB;C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\LIB\\amd64;C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\bin\\amd64;C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\PlatformSDK\\Lib;C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.1A\\Lib\\x64;C:\\Program Files (x86)\\Intel\\Composer XE 2013 SP1\\mkl\\lib\\intel64;
Would appreciate it if you could help me to figure out the source of the problem.
Thanks,
Alireza
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The full list of compiler options I used are:
/compile_only /free /Warn:alignments /Warn:declarations /Warn:errors /Warn:general /align:dcommons /nologo /module:modules /Qzero /O2 /heap-arrays:1 /traceback /check:bounds /Qmkl /iface:cref
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you use /iface:cref, the case used for external names becomes lower-case. However, the MKL libraries contain Lapack routine names such as dpotrf_f95 in upper-case, i.e., as DPOTRF_F95, which is why the linking failed.
Do you need /iface:cref? Can you just leave that option out and try?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the response. The problem is that to link to Abaqus, one needs to include /iface:cref.
I wonder if there is a compiler directive to use within my subroutine that tells not to use iface:cref when interfacing a specific call within the subroutine.
Thanks,
Alireza
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can understand Abaqus requiring the use of /iface:cref in the 32-bit world. In 64-bits, however, the difference between /iface:cref and the default is very slight (the case of external names being one such). Which version of Intel Fortran does Abaqus suggest using in its documentation?
Try the /names:uppercase option, but note that while such options may help you to fix the immediate issue, they may well create problems elsewhere.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Abaqus recommends Intel Fortran Compiler 12.1 but I have XE 2013 SP1.
For the 32 bit compilation, Abaqus has both '/iface:nomixed_str_len_arg' and '/iface:cref' wheras for 64 bit it only has '/iface:cref'.
I will give uppercase a try.
Thanks
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page