topic Linking error in Intel® oneAPI Math Kernel Library

Linking error

Alireza_Forghani — Mon, 15 Dec 2014 21:34:46 GMT

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

The full list of compiler

Alireza_Forghani — Mon, 15 Dec 2014 21:49:08 GMT

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

When you use /iface:cref, the

mecej4 — Tue, 16 Dec 2014 03:33:00 GMT

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?

Thanks for the response. The

Alireza_Forghani — Wed, 17 Dec 2014 17:50:05 GMT

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

I can understand Abaqus

mecej4 — Wed, 17 Dec 2014 18:48:43 GMT

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.

Abaqus recommends Intel

Alireza_Forghani — Wed, 17 Dec 2014 18:55:04 GMT

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