- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using IPP IA32, compile passed and can run. But after using IPP Intel64, got following massage,
"
Error 7 error LNK2019: unresolved external symbol _ippGetStatusString@4 referenced in function _main C:\Users\jingwang\documents\visual studio 2013\Projects\Project_intel64\Project_intel64\Source_intel64.obj Project_intel64
Error 8 error LNK2019: unresolved external symbol _ippInit@0 referenced in function _main C:\Users\jingwang\documents\visual studio 2013\Projects\Project_intel64\Project_intel64\Source_intel64.obj Project_intel64
Error 9 error LNK2019: unresolved external symbol _ippGetEnabledCpuFeatures@0 referenced in function _main C:\Users\jingwang\documents\visual studio 2013\Projects\Project_intel64\Project_intel64\Source_intel64.obj Project_intel64
Error 10 error LNK2019: unresolved external symbol _ippiGetLibVersion@0 referenced in function _main C:\Users\jingwang\documents\visual studio 2013\Projects\Project_intel64\Project_intel64\Source_intel64.obj Project_intel64
Error 11 error LNK1120: 4 unresolved externals C:\Users\jingwang\documents\visual studio 2013\Projects\Project_intel64\Debug\Project_intel64.exe Project_intel64
"
I have set the similar path in link/include/Executable of project.
If using intel64, any other option need to add?
Thanks,
Jing
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jing,
Could you check that your project properties/C/C++/Advanced/Calling Convention property is set to "__cdecl (/Gd)".
Not "stdcall" and not "fastcall".
Regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jing, my two cents - have you linked with 64 bit IPP's libraries?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi Sergey,
I check the "project properties/C/C++/Advanced/Calling Convention " is set to "__cdecl (/Gd)".
I am using Microsoft Visual Studio 2013, is it possible this Microsoft Visual Studio 2013 only support 32bits operation?
Sergey Khlystov (Intel) wrote:
Hi Jing,
Could you check that your project properties/C/C++/Advanced/Calling Convention property is set to "__cdecl (/Gd)".
Not "stdcall" and not "fastcall".
Regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Gennady,
I have linked the 64bits IPP lib as following
add project Property -> C/C++ -> General -> Executable Directories -> C:\Intel\Composer XE 2013 SP1.083\redist\intel64\ipp\;
add project Property -> C/C++ -> General -> Include Directories -> C:\Intel\Composer XE 2013 SP1.083\ipp\include\;
add project Property -> C/C++ -> General -> Library Directories -> C:\Intel\Composer XE 2013 SP1.083\ipp\lib\intel64\;
if I modify above "intel64" to "ia32", it can work.
I am using Microsoft Visual Studio 2013, is it possible this Microsoft Visual Studio 2013 only support 32bits operation?
Gennady Fedorov (Intel) wrote:
Jing, my two cents - have you linked with 64 bit IPP's libraries?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Jing,
I don't have 2013 version available, but I used your test1_0.cpp file and create MVSC 2010 solution for 64 bit. See at this project into attachment.
here are the output and build log files. the version of IPP - 8.1
ippIP AVX (e9) 8.1.0 (r41650)
SSE :Y
SSE2 :Y
SSE3 :Y
SSSE3 :Y
SSE41 :Y
SSE42 :Y
AVX :Y
AVX2 :N
----------
OS Enabled AVX :Y
AES :N
CLMUL :Y
RDRAND :N
F16C :N
Press any key to continue . . .
=====================
Creating "Debug\test.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>MessageBuildingWithCompiler:
1> Building with Intel(R) C++ Compiler XE 14.0
1>ClCompile:
1> ***** ClCompile (x64 - Intel C++)
1> test1_0.cpp
1>Link:
1> xilink: executing 'link'
1>Manifest:
1> Deleting file "Debug\test.exe.embed.manifest".
1>LinkEmbedManifest:
1> xilink: executing 'link'
1> tmp.vcxproj -> C:\_tmp\_Forums\ipp_u507095\Debug\test.exe
1>FinalizeBuildStatus:
1> Deleting file "Debug\test.unsuccessfulbuild".
1> Touching "Debug\test.lastbuildstate".
1>
1>Build succeeded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is something special in how MS x64 linker generates the names of external functions in object files. I don't remember exactly, but the
suppose that you have the following program:
extern "C" { void _stdcall foo(); } int main() { foo(); }
The "foo" is declared like IPP function should be declared. In VS2013 on x64 you will get:
1>Source.obj : error LNK2019: unresolved external symbol foo referenced in function main
For win32 the diagnostics is:
1>Source.obj : error LNK2019: unresolved external symbol _foo@0 referenced in function _main
This difference in function name decorations in object file is reflected in IPP libraries. For win32 flavor (win32 libs) the names are decorated as _<function_name>@<stack_size>. If you look into library files with
> dumpbin /exports ippcore.lib | find "ippGetStatusString"
you will see "_ippGetStatusString@4" for win32 libs and "ippGetStatusString" for intel64 libs.
You can do the same experiments in your environment. Make sure your "x64" project is consistent.
Regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Gennady,
This issue is fixed. Because my project set to win32, but x64. After set to x64, it can works.
Thanks,
Jing
Gennady Fedorov (Intel) wrote:
and here is the VS2010 solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sergey,
This issue is fixed. Because my project set to win32, but x64. After set to x64, it can works.
Thank you of reminding me about this.
Thanks,
Jing
Sergey Khlystov (Intel) wrote:
There is something special in how MS x64 linker generates the names of external functions in object files. I don't remember exactly, but the
suppose that you have the following program:extern "C" { void _stdcall foo(); } int main() { foo(); }The "foo" is declared like IPP function should be declared. In VS2013 on x64 you will get:
1>Source.obj : error LNK2019: unresolved external symbol foo referenced in function main
For win32 the diagnostics is:
1>Source.obj : error LNK2019: unresolved external symbol _foo@0 referenced in function _mainThis difference in function name decorations in object file is reflected in IPP libraries. For win32 flavor (win32 libs) the names are decorated as _<function_name>@<stack_size>. If you look into library files with
> dumpbin /exports ippcore.lib | find "ippGetStatusString"
you will see "_ippGetStatusString@4" for win32 libs and "ippGetStatusString" for intel64 libs.You can do the same experiments in your environment. Make sure your "x64" project is consistent.
Regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
perfect, thanks for the update.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page