Linking errors using IPP 9.0 legacy libraries

Linking errors using IPP 9.0 legacy libraries

I'm trying to update a library built with IPP 8.2.1 to the 2017.0.109 version. It used the IPP some function from computer vision domain that has been removed  from official IPP product, so I downloaded and install the IPP 9.0 legacy libraries (ipp90legacy_win_9.0.0.008).

I've updated the corresponding sources, it's compiling fine, but when doing [static] linking, I get some errors for symbols conflict between ippcv90lgcmt.lib and ippcoremt.lib :

1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownGetMaskFeatures already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownGetFeature already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownSetFeatureMask already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownMaskIsFeatures already defined in ippcv90lgcmt.lib(owncpufeatures.obj)

Problem arise only if I call function ippGetEnabledCpuFeatures(). Removing the call linker terminate w/o errors.

Thank's in advance

publicaciones de 12 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Dear customer,

Here's the article talking about the usage of IPP legacy lib. If you are using dynamic linking, there would not be any problem. But if you would like to link statically, you probably need to call legacy90ipp<domain>Init() at first, otherwise IPP will auto-initialized from IPP domain lib (the domain for the fist function you are calling) not calling from IPP core lib. Another point is that you probably need to pay attention to dependency of IPP domain lib. Hope it would be helpful to you.

Best regards,
Fiona

Hi Fiona,

from the first document :

"Therefore, the legacy flavor of the IPP 9.0 static library doesn’t require any special stage for initialization; the best optimization layer is dispatched automatically." 

so my original program doesn't call any initialization function for the legacy domain.

Below a reduced sample that reproduce the error. If  you comment out the function call ippGetEnabledCpuFeatures() error disappear. Call to legacy90ippcvInit() is not relevant.

#include "stdafx.h"

#include <ipp.h>

#include <ippcv90legacy.h>

int main()
{
	ippInit();

	auto fm = ippGetEnabledCpuFeatures();
	
	auto lgcInit = legacy90ippcvInit();


	const Ipp32f* pSrc=nullptr;
	int srcStep{ 0 };
	Ipp32f* pDst = nullptr;
	int dstStep{ 0 };
	IppiSize roiSize{ 0,0 };
	Ipp8u* pBuffer{ nullptr };

	IppStatus st = ippiPyrUp_Gauss5x5_32f_C1R( pSrc,  srcStep,
		pDst,  dstStep,
		roiSize, pBuffer);

    return 0;
}

Building with VS2015 produces this output :

1>------ Build started: Project: testIppLegacy, Configuration: Debug x64 ------
1>  testIppLegacy.cpp
1>d:\works\gitlocal\develop\testcu\testipplegacy\testipplegacy.cpp(16): warning C4996: 'legacy90ippcvInit': Function from IPP 9.0 legacy domain is used
1>  e:\3rdpartylibrary\software\ipp\ipp90legacy_win_9.0.0.008\include\ippcv90legacy.h(58): note: see declaration of 'legacy90ippcvInit'
1>d:\works\gitlocal\develop\testcu\testipplegacy\testipplegacy.cpp(26): warning C4996: 'legacy90ippiPyrUp_Gauss5x5_32f_C1R': Function from IPP 9.0 legacy domain is used
1>  e:\3rdpartylibrary\software\ipp\ipp90legacy_win_9.0.0.008\include\ippcv90legacy.h(1361): note: see declaration of 'legacy90ippiPyrUp_Gauss5x5_32f_C1R'
1>  LINK : D:\Works\GITLocal\Develop\testCu\x64\Debug\testIppLegacy.exe not found or not built by the last incremental link; performing full link
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownGetMaskFeatures already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownGetFeature already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownSetFeatureMask already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>ippcoremt.lib(owncpufeatures.obj) : error LNK2005: ownMaskIsFeatures already defined in ippcv90lgcmt.lib(owncpufeatures.obj)
1>D:\Works\GITLocal\Develop\testCu\x64\Debug\testIppLegacy.exe : fatal error LNK1169: one or more multiply defined symbols found
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Ipp libraries needed are implicitly inserted by #pragma comment in ipp header (I've _IPP_SEQUENTIAL_STATIC defined). In this sample I've added the whole bunch of legacy static libraries ( ipp<xxx>90lgcmt.lib ).

Best regards

Giacomo

 

 

Dear customer,

The root cause is that there's duplicated definition of those symbol in both main package and legacy package. Actually Ipp legacy package is independent of main package.  Nomorlly we pick one of them to use. But according to your program, the getCpuFeature function belogns to main package, but the pyramid  upsampling of Guassin image is in legacy package. To avoid this problem, please link with main package(core) dynamically, and link with legacy cv lib statically. For instance, the link line should be like:

>icl ippcv_problem.cpp -I"%IPPROOT%"\include -I"%IPPROOT_LEGACY%"\include -Qipp "%IPPROOT_LEGACY%"\lib\intel64\ippcv90lgcmt.lib

And you won't get link error for duplicated definition problem.

Best regards,
Fiona

Hi Fiona,

thank's for your feedback, but for me isn't an option dynamically link the main package. Our applications are always distributed with IPP statically linked. I use the latest IPP version mixed with legacy to support some function that has been removed like ippPyrUp_Gauss5x5. One option for me could be to realize a small dll statically linked to legacy IPP that exports the only functions needed and than link this library to the application ... not so good.

Thank's

Giacomo

 

 

 

Hi Giacomo,

you can get rid of legacy lib at all - just substitute APIs you use with new APIs - for example instead of PyrUp_Gauss5x5 you can use the next APIs:

/* ///////////////////////////////////////////////////////////////////////////////////////
//  Name:       ippiPyramidLayerDown_8u_C1R, ippiPyramidLayerDown_16u_C1R, ippiPyramidLayerDown_32f_C1R
//              ippiPyramidLayerDown_8u_C3R, ippiPyramidLayerDown_16u_C3R, ippiPyramidLayerDown_32f_C3R
//              ippiPyramidLayerUp_8u_C1R,   ippiPyramidLayerUp_16u_C1R,   ippiPyramidLayerUp_32f_C1R
//              ippiPyramidLayerUp_8u_C3R,   ippiPyramidLayerUp_16u_C3R,   ippiPyramidLayerUp_32f_C3R
//
//  Purpose:    Perform downsampling/upsampling of the image with 5x5 gaussian.
//
//  Return:
//    ippStsNoErr              Ok
//    ippStsNullPtrErr         One of the specified pointers is NULL
//    ippStsSizeErr            The srcRoiSize or dstRoiSize has a fild with zero or negativ value
//    ippStsStepErr            The steps in images are too small
//    ippStsBadArgErr          pState->rate has wrong value
//    ippStsNotEvenStepErr     One of the step values is not divisibly by 4 for floating-point
//                             images, or by 2 for short-integer images.
//  Arguments:
//    pSrc                     Pointer to the source image
//    srcStep                  Step in byte through the source image
//    srcRoiSize               Size of the source image ROI in pixel.
//    dstRoiSize               Size of the destination image ROI in pixel.
//    pDst                     Pointer to destination image
//    dstStep                  Step in byte through the destination image
//    pState                   Pointer to the pyramid layer structure
*/

regards, Igor

 

Hi Igor,

I 've tryed universal pyramid function with old IPP version but they are slower than specialized ones. I can try again using latest IPP 2017.1

Thank's

 

Hello,

yes, there are some issues in IPP 9.0 Legacy package, thank you to identify them. Will fix them.

Pavel

Any news about symbol duplication in legacy lib?

Hello,

I'm very sorry for my silence. We detected an issue in IPP legacy nonpic libraries and we are going to fix it before updating the libraries. It is in progress. Thank you for your patience.

Pavel

Hello Parvel,

I have similar issue in another thread

Does building our application with IPPLegacy 9.0 still require us to link against IPP main package (Lib/Include) ?

As while building our source-code with the IPPLegacy library I observe below specific issues:

1)For function likes IPPFree () or IPPMalloc () we still have to link with the ippcore lib  from the man package.

2)The function ippiMirror_8u_C1R() is not available in ippilegacy.h file of IPP9Legacy library and we still have to include ippi.h

and link with with ippi.a lib from main package..

3)Similarly for function like ippsCopy_8u() we still have to link with ipps.h and libipps.lib from main package and it is not available in

IPPLegacy package (ippslegacy.h. libipp90lgc.a)  

Although its written in one of the articled that   "all legacy domains are self-sufficient".

We are using IPP9legcay pacakge for Linux OS , Do we have to use latest main IPP package along with it or can we link  with IPP9.0 or older main package also? Please provide the download link for IPP9.0 main package to be used in Linux along with IPP9Legacy . 

Thanks

Manish Narang

Hello Manish,

sorry for the delay with answer. IPP legacy domains contain only removed algorithms. ippsCopy_8u() is in the modern IPP version, we continue to support the algorithm, so yes, it is not in IPP legacy, it presents in the modern IPP version and you need to use the modern IPP version together with IPP legacy domains.

https://software.intel.com/en-us/articles/intel-ipp-legacy-libraries

To smooth the code transition, Intel IPP provides a separate package called "Legacy Libraries". This package is independent from Intel® IPP product and contains the major removed functions in Intel IPP 9.0 as well as the deprecated functions in previous Intel® IPP releases.

Pavel 

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya