Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

cannot compile IPP intel64

jing_w_
Beginner
1,208 Views

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

 

0 Kudos
10 Replies
Sergey_K_Intel
Employee
1,208 Views

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

0 Kudos
Gennady_F_Intel
Moderator
1,208 Views

Jing, my two cents -  have you linked with 64 bit IPP's libraries?

0 Kudos
jing_w_
Beginner
1,208 Views

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

0 Kudos
jing_w_
Beginner
1,208 Views

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?

0 Kudos
Gennady_F_Intel
Moderator
1,208 Views

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.

 

 

0 Kudos
Sergey_K_Intel
Employee
1,208 Views

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

0 Kudos
Gennady_F_Intel
Moderator
1,208 Views

and here is the VS2010 solution 

0 Kudos
jing_w_
Beginner
1,208 Views

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

0 Kudos
jing_w_
Beginner
1,208 Views

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 _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

0 Kudos
Gennady_F_Intel
Moderator
1,208 Views

perfect, thanks for the update.

0 Kudos
Reply