Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

static library link error

haijunwu
Beginner
536 Views

I create a static library in the main project folder, add the static library as an existing project into the main project and set the project dependencies. When I build them , the link errs happens as follows

Error 1 error LNK2019: unresolved external symbol _SPBESH@16 referenced in function _ML ML.obj
Error 2 error LNK2019: unresolved external symbol _LPN@16 referenced in function _ML ML.obj
Error 3 error LNK2019: unresolved external symbol _DNLPMN@20 referenced in function _CHRISDAR ChrisDar.obj
Error 4 error LNK2019: unresolved external symbol _NLPMN@20 referenced in function _PRECOMPUTE PreCompute.obj
Error 5 error LNK2019: unresolved external symbol _CREATERWU@96 referenced in function _MAIN__ Diag.obj

But in another project, I also add the same static into the project, it works. So I dont why.

0 Kudos
2 Replies
Jugoslav_Dujic
Valued Contributor II
536 Views
Quoting - haijunwu

I create a static library in the main project folder, add the static library as an existing project into the main project and set the project dependencies. When I build them , the link errs happens as follows

Error 1 error LNK2019: unresolved external symbol _SPBESH@16 referenced in function _ML ML.obj
Error 2 error LNK2019: unresolved external symbol _LPN@16 referenced in function _ML ML.obj
Error 3 error LNK2019: unresolved external symbol _DNLPMN@20 referenced in function _CHRISDAR ChrisDar.obj
Error 4 error LNK2019: unresolved external symbol _NLPMN@20 referenced in function _PRECOMPUTE PreCompute.obj
Error 5 error LNK2019: unresolved external symbol _CREATERWU@96 referenced in function _MAIN__ Diag.obj

But in another project, I also add the same static into the project, it works. So I dont why.


There is no enough data, so I have to guess. The name decoration suggests that the caller (ML, CHRISDAR) uses IVF default calling convention (names uppercase, C), but the called routines (from the library?) SPBESH, LPN etc. use CVF calling convention (names uppercase, STDCALL).

If I'm right, the simplest workaround is to specify /iface:cvf in your compiler settings. (Project/Settings/Fortran/External routines/Calling convention -> CVF).

0 Kudos
haijunwu
Beginner
536 Views
Quoting - Jugoslav Dujic

There is no enough data, so I have to guess. The name decoration suggests that the caller (ML, CHRISDAR) uses IVF default calling convention (names uppercase, C), but the called routines (from the library?) SPBESH, LPN etc. use CVF calling convention (names uppercase, STDCALL).

If I'm right, the simplest workaround is to specify /iface:cvf in your compiler settings. (Project/Settings/Fortran/External routines/Calling convention -> CVF).


Thanks, Jugosav Dujic. It works in debug model by setting calling convention as you said.

But new error happens in the realease mode. After the main project calling one suboutine defined in a static library , some variables in calling subroutine changed so the run time error happens as
"forrtl: severe (157): Program EXception - access violation"

I checked the argument lists of the subroutine, they are right. Confusion is thatif I create a new project by using the source file in the static library instead of adding static library into project. The progrme can be run in both debug and realease.So what's the problem probably be.



0 Kudos
Reply