topic Hi Gennady, in Intel® Integrated Performance Primitives

cannot compile IPP intel64

jing_w_ — Thu, 13 Mar 2014 09:29:46 GMT

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

Hi Jing,

Sergey_K_Intel — Thu, 13 Mar 2014 09:57:51 GMT

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

Jing, my two cents - have

Gennady_F_Intel — Thu, 13 Mar 2014 11:15:32 GMT

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

hi Sergey,

jing_w_ — Fri, 14 Mar 2014 01:30:32 GMT

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

Hi Gennady,

jing_w_ — Fri, 14 Mar 2014 01:35:11 GMT

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?

Hello Jing,

Gennady_F_Intel — Fri, 14 Mar 2014 06:43:23 GMT

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.

There is something special in

Sergey_K_Intel — Fri, 14 Mar 2014 06:47:00 GMT

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

and here is the VS2010

Gennady_F_Intel — Fri, 14 Mar 2014 06:48:38 GMT

and here is the VS2010 solution

Hi Gennady,

jing_w_ — Fri, 14 Mar 2014 08:43:24 GMT

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

Hi Sergey,

jing_w_ — Fri, 14 Mar 2014 08:44:21 GMT

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

perfect, thanks for the

Gennady_F_Intel — Fri, 14 Mar 2014 18:05:53 GMT

perfect, thanks for the update.