cannot compile IPP intel64

cannot compile IPP intel64

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

 

AllegatoDimensione
Download test1_0.cpp1.27 KB
11 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

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

Regards,
Sergey

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

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?

 

Citazione:

Sergey Khlystov (Intel) ha scritto:

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,

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?

 

Citazione:

Gennady Fedorov (Intel) ha scritto:

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

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

Regards,
Sergey

and here is the VS2010 solution 

Allegati: 

AllegatoDimensione
Download ipp_u507095.zip7.03 KB

Hi Gennady,

This issue is fixed. Because my project set to win32, but x64. After set to x64, it can works.

 

Thanks,

Jing

 

Citazione:

Gennady Fedorov (Intel) ha scritto:

and here is the VS2010 solution

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

Citazione:

Sergey Khlystov (Intel) ha scritto:

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 update.

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi