Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
22 Views

Linking error

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

 

0 Kudos
5 Replies
Highlighted
22 Views

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

0 Kudos
Highlighted
Black Belt
22 Views

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?

 

0 Kudos
Highlighted
22 Views

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

0 Kudos
Highlighted
Black Belt
22 Views

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.

 

0 Kudos
Highlighted
22 Views

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

 

 

0 Kudos