Linking issues with ipp 8.1

Linking issues with ipp 8.1

Hallo,

today i updated intel studio xe with sp1 udate 2 and also the ipp from 8.0 to 8.1. (Visual Studio 2013 Professional)

I'am using intel compiler 14.0.2 now.

In x86 mode everthing will be compiled and linked, but under x64 i got a lot of linker errors. (static singlethreaded)

It seems that  the pragma lib does'nt work any more.

After reverting to sp1 Update 1 everything was compiled and linked in both modes (x86 & x64). So i updated again to sp1 update 2 and i got the same linker errors in x64 mode. So i added the ipp-libs directly in the linker option (additional lib) and now it works. Maybe it is a problem  of the compiler crew, so pls delegate this problem to them.

 

Best regards

Detlef

13 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

do you this mode: #pragma comment ( lib, "xxxxxx.lib" ) ?  Which libraries did you try to link? 

I havn't added any pragma lib to any of my sources.

II think the problem is the pragma lib in the intel ipp headers, because they have a relative path. In x86 just it works, in x64 mode not.

I'am linking static single threaded, also is defined _IPP_SEQUENTIAL_STATIC under Preprocessor Defines and  under "Capter Intel IPP Settting" in Configuration Properties i set all to static single threaded.

 

 

Ok, thanks for bringing the issue. I see the similar behavior on my side too. It looks like the compiler’s issue and we will try to address it to the compiler's team. 

--Gennady

The problem has been escalated to  the compiler team. Here is the number DPD200512536 for further reference. We will update this  thread in the case if any update. Thanks for the issue.

Hi Gennady,

I just noticed a (buggy?) change in the IPP headers which could account for this problem.  It looks like all of the "#pragma comment" lines have been changed from

#if !defined( _IPP_NO_DEFAULT_LIB )
  #if defined( _IPP_SEQUENTIAL_DYNAMIC )
    #pragma comment( lib, "ippch" )
    #pragma comment( lib, "ippcore" )
  #elif defined( _IPP_SEQUENTIAL_STATIC )
    #pragma comment( lib, "ippchmt" )
    #pragma comment( lib, "ippsmt" )
    #pragma comment( lib, "ippvmmt" )
    #pragma comment( lib, "ippcoremt" )
  #elif defined( _IPP_PARALLEL_DYNAMIC )
    #pragma comment( lib, "threaded/ippch" )
    #pragma comment( lib, "threaded/ippcore" )
  #elif defined( _IPP_PARALLEL_STATIC )
    #pragma comment( lib, "threaded/ippchmt" )
    #pragma comment( lib, "threaded/ippsmt" )
    #pragma comment( lib, "threaded/ippvmmt" )
    #pragma comment( lib, "threaded/ippcoremt" )
  #endif
#endif

to

#if !defined( _IPP_NO_DEFAULT_LIB )
  #if defined( _IPP_SEQUENTIAL_DYNAMIC )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "ippch" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "ippcore" )
  #elif defined( _IPP_SEQUENTIAL_STATIC )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "ippchmt" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "ippsmt" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "ippvmmt" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "ippcoremt" )
  #elif defined( _IPP_PARALLEL_DYNAMIC )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "threaded/ippch" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "threaded/ippcore" )
  #elif defined( _IPP_PARALLEL_STATIC )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "threaded/ippchmt" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "threaded/ippsmt" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "threaded/ippvmmt" )
    #pragma comment( lib, __FILE__ "/../../lib/" _INTEL_PLATFORM "threaded/ippcoremt" )
  #endif
#endif

 

There is no way to guarantee that the libs are always in a path relative to the file currently being compiled.  I hope this helps.

Peter

Hello all

 

did you solve this problem? We need to link as before, so using our existing path instead of ../../lib and we do not want to change any code in the ipp headers. Any update?

I just checked IPP 8.2, and it looks like they have not updated the IPP header files.  They are still using /../../lib which does not work for me either as I need to have IPP in our source control instead of relying on everyone installing the correct version.  I finally broke down and started correcting the IPP headers manually.

Peter

 

Thank you, we will check integration into MSVC 2013. In any cases you can link IPP libraries dirrectly in your project if integration is brocken. You should point $(IPPROOT)/lib/intel64 in Library Path option and point IPP libraries which you would like to link, for example:

ippimt.lib ippsmt.lib ippcoremt.lib

Pavel

Hi Peter,

"/../../lib" paths used in IPP headers are not relative to currently compiled source, but to header file itself. The variant without relative paths didn't work on VS2008/VS2010 for threaded libraries. Could you clarify how do you use IPP library (using "Intel Performance Libraries->Use Intel IPP" property or somehow else) and what errors do you get? Is it the same issue as described in the beginning of the thread (win32 platform is built, x64 is not)?

Vadim

Hi Pavel and Vadim,

Yes, I can just explicitly link with the libraries, but I do like the way you use to have it with auto link using pragmas.

What I have done specifically is commit the lib files to my source control in a directory which is already in the library path.  This way I don't have to worry about what version of Composer each developer has installed on their machine.

Peter

Is my understanding correct that you have IPP libraries under source control, but this is not true for IPP headers?
IPP libraries are searched relatively to IPP headers, so all you need is to add full IPP folder to source control (with keeping the structure) and add corresponded "ipp\include" path to "C++>General>Additional Include Directories". Setting library path to IPP libs folder is not required.

Vadim

Thanks Vadim, I'll give that a try.

Peter

Lascia un commento

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