Static Linking Error - ippcore-7.1 Dependency

[Royi]

Hello,

I have Intel Composer 2012 XE with Intel IPP 7.1.0.089.

I set in the project properties under Intel Libraries - "Use IPP: Single Threaded Static Library".

Yet after compiling I still get dependency of 'ippcore-7.1' and only 'ippcore-7.1'.

I use Intel Compiler for the compiling process.

How could that be? How could that be resolved? I think it is a bug since I use MS Compiler I don't have that dependency (Same settings).

I use Windows 7 64 Bit.

All paths are defined well.

[petervk]

I should also add that per section 3.3 of the documentation for Composer 2013, the /Qipp-link:{static|dynamic|static_thread} should be available. As noted above, on Windows with VS2012, they are not.

Reading the Intel C++ Compiler XE 13.1 User and Reference Guides, you will note that /Qipp is an option, although static, etc. are not listed. The reference guide correctly states that there is no setting in the IDE to enable /Qipp, however manually adding any /Qipp:lib option to the linker command line results in an "unknown option" error and executables that do not link to the IPP libraries. The documentation states that this is the default behavior and this is correct. Without the ability to specify IPP linking options, Studio XE 2013 is a broken product for many Windows applications that use IPP,

[SergeyKostrov]

>>...The problem appears with the combination of Intel Studio XE 2013 and Visual Studio 2012, not VS2008. When VS 2012 is used, >>there no longer is an option to enable /Qipp and /Qipp-link:static... I will verify it.

[SergeyKostrov]

>>>>...The problem appears with the combination of Intel Studio XE 2013 and Visual Studio 2012, not VS2008. When VS 2012 is used, >>>>there no longer is an option to enable /Qipp and /Qipp-link:static... >> >>I will verify it. Verified with Intel C++ Compiler XE 13.1.0.149 [ IA-32 & X64 ] ( Update 2 ) and both options are present. Should I attach a screenshot? We're back to some discussion with statements like '...The problem appears... ' without providing a real reproducer of the problem. My conclusion is: Visual Studio ( any version ) project Reproducer, please.

[petervk]

Sergey Kostrov wrote:

>>>>...The problem appears with the combination of Intel Studio XE 2013 and Visual Studio 2012, not VS2008. When VS 2012 is used,
>>>>there no longer is an option to enable /Qipp and /Qipp-link:static...
>>
>>I will verify it.

Verified with Intel C++ Compiler XE 13.1.0.149 [ IA-32 & X64 ] ( Update 2 ) and both options are present. Should I attach a screenshot?

Yes please. Using VS2012 + Composer XE 2013.3.171 (Update 3), the /Qipp options are not present in the IDE. As I mentioned above, this is consistent with Intel's documentation. Enabling any /Qipp option on the command line results in an error.

Sergey Kostrov wrote:

We're back to some discussion with statements like '...The problem appears... ' without providing a real reproducer of the problem. My conclusion is:

Visual Studio ( any version ) project Reproducer, please.

I'll work on it. Hopefully it will be an easy test case. All the apps we have experienced this bug with use broad swaths of the IPP functionality. If triggering the bug requires obscure functions, it may be more difficult to track down.

Going back to earlier posts by others, I triggered the bug reported when the Intel Optimized headers were used. If they are, both ippcore-7.1.dll and libiomp5md.dll are required. The libiomp5md.dll problem previously could be avoided by diasbling /Qparallel. Now, however using the INTC optimized headers results n code that dynamically links to both the OpenMP and IPP dll's. Not using the Intel headers makes an application that happily runs without either dll.

I'll try to spin up a test case.

[petervk]

Unfortunately, developing a simple test case is proving non-trivial. I have built simple applications using a few IPP routines and have not been able to trigger the errors even when Qipp-link:static is not specified on the command line. Sorry, I don't have the time to comb through 500K+ lines of code to find the routine(s) that trigger the odd behavior.

On the plus side, I finally figured out why /Qipp-link:static was not working as intended: Each of the problem apps contains multiple dependencies. I had not put /Qipp-link:static into the compiler options in each and every one. Once I did, voila, no more dependency on the IPP dll files. Note that this is a departure from previous Intel compiler behavior. Not using the Intel Optimized headers is an alternative path to avoiding dynamic linkage. Performance suffers if you go that route.

[SergeyKostrov]

Hi Peter, >>Yes please. Using VS2012 + Composer XE 2013.3.171 (Update 3), the /Qipp options are not present in the IDE. >>As I mentioned above, this is consistent with Intel's documentation. Enabling any /Qipp option on the command >>line results in an error. I will follow up on it and another thread will be created in Intel C++ compiler forum. It looks very strange and needs to be verified. >>...I had not put /Qipp-link:static into the compiler options in each and every one. Once I did, voila, no more >>dependency on the IPP dll files... Finally resolved! Thanks. Note: All these project related things need to be monitored and verified as better as possible. It takes for me half a day to go through several solutions with more than 70 Visual Studio projects when updates in project settings are needed.

[petervk]

What caught me was that some of the sub-projects in the VS2012 solution did not use IPP at all, and some were even compiled with Visual C++ rather than Intel C++. These projects created library files that were later used by the main project. Every single one of the projects, whether or not IPP was used, needed to be modified to use the Intel compiler and have the /Qipp /Qipp-link:static options added to the compiler command line.

If any project in the solution did not use the Intel compiler with  /Qipp-link:static specified, the resulting executable dynamically links against the IPP libraries. Needless to say, this appears more like a bug than expected behavior on the compiler's part.

[SergeyKostrov]

Hi Peter, Thank for the update. >>...If any project in the solution did not use the Intel compiler with /Qipp-link:static specified, the resulting executable >>dynamically links against the IPP libraries... This is what command line helps show: Intel C++ Compiler XE 12.1.7.371 [ IA-32 ] ( Update 7 ) ... /Qipp[:] link some or all of the Intel(R) Integrated Performance Primitives (Intel(R) IPP) libraries and bring in the associated headers common - link using the main libraries set. This is the default value when /Qipp is specified crypto - link using the main libraries set and the crypto library gen - link using the main libraries set and the fixed size generated functions library ... Note: There are No any comments for /Qipp-link: option ( it is missing for that version of Intel C++ compiler ) Intel C++ Compiler XE 13.1.0.149 [ IA-32 & X64 ] ( Update 2 ) ... /Qipp-link: choose whether to link with static or dynamic libraries to support Intel(R) Integrated Performance Primitives (Intel(R) IPP) dynamic - link using the dynamic libraries set. This is the default value when /Qipp is specified on Windows static - link using the static libraries set. This is the default value when /Qipp is specified on Linux static_thread - link using the optional threaded libraries set Note: these are provided in a separate install kit ...

[Jan_W_1]

Hello,

I have the same problem with the "This application has failed to start because ippcore-7.1.dll was not found." error.
I'm using VS2012 and I cant' use the Intel Compiler but have to use the VC++ Compiler with Plattform Toolset of VS2008.

Starting with Intel Composer XE 20013 I'm suddenly not able to run Debug builds anymore. 
With IPP 6.X I was able to statically link to IPP and successfully run the Debug builds. Now this isn't possible anymore because of the missing dependency.

I cannot set the  /Qipp /Qipp-link:static option because I have to use the VS Compiler. This really seems like a bug to me.
Could someone please take a look at this?

Thank you. 

[SergeyKostrov]

This is Not a bug. >>...I have the same problem with the "This application has failed to start because ippcore-7.1.dll was not found." error... Please check search paths to a Redist directory ( 32-bit or 64-bit ) with IPP DLLs.

[Sergey_K_Intel]

Hi Jan W,

Let me bescribe the required steps. Look first at the conditional compilation constructions, which are in every ipp*.h files (I took ippac.h as an example, just because it is first in the list of header files):

[cpp]

#if !defined( _IPP_NO_DEFAULT_LIB )
    #if defined( _IPP_PARALLEL_DYNAMIC )
        #pragma comment( lib, "ippac" )
        #pragma comment( lib, "ippcore" )
    #elif defined( _IPP_PARALLEL_STATIC )
        #pragma comment( lib, "ippac_t" )
        #pragma comment( lib, "ippdc_t" )
        #pragma comment( lib, "ipps_t" )
        #pragma comment( lib, "ippcore_t" )
    #elif defined( _IPP_SEQUENTIAL_STATIC )
        #pragma comment( lib, "ippac_l" )
        #pragma comment( lib, "ippdc_l" )
        #pragma comment( lib, "ipps_l" )
        #pragma comment( lib, "ippcore_l" )
    #endif
#endif

[/cpp]

Suppose that we want to turn off automatic compiler-controlled linking completely. I would define _IPP_NO_DEFAULT_LIB macro before #include <ipp*..h> statements, or in project compiler/preprocessor property or in compiler command line, whatever.

OK, so now linker knows nothing about IPP. We need to tell linker where to search for library files. Set project's property "Configuration Properties/Linker/General/Additional Library Directories" to (in my case) "C:\Program Files (x86)\Intel\Composer XE 2013\ipp\lib\ia32". Or, it will be another directory in your case, shortly speaking, to the directory where ippac.lib/ippac_l.lib files are located (remember, that we take IPPAC as an example). Also you should remember about 32-bit/64-bit architecture differences.

Then, there are two kinds of libraries in that directory. ipp*.lib and ipp*_l.lib. The first libs (e.g. ippac.lib) are smaller than the second. The first libs (without _l suffix) are DLL export libs (or, stub libs). They contain no function object code inside and describe only entries within corresponding DLLs. If you link your application with these libs, your application will be constantly asking about DLLs. You need to put IPP DLLs next to your application binary, or modiy PATH variable (set PATH=%PATH%;C:\Program Files (x86)\Intel\Composer XE 2013\redist\ia32\ipp) so, that Windows will know where to locate DLLs. Even in this case you can debug your application using VS, but the modified PATH variable should be active BEFORE you start VS. It means, that you need update PATH in system/user settings of your computer. Or, to start "devenv.exe" from command line after to set the PATH variable.

The second (bigger) libraries are real static libs and contain IPP function object code inside. If you link your application with these libraries, the application won;t need IPP DLLs anymore.

The difference between linking to static or dynamic libraries is simply the difference between the library names, which you use in "Configuration Properties/Linker/Input/Additional Dependencies" property of your project, If you set "ippac.lib; ippdc.lib; ipps.lib;ippcore.lib" there, you will link your application to dynamic IPP libs. If you specify "ippac_l.lib; ippdc_l.lib; ipps_l.lib;ippcore_l.lib", your application will be linked statically. The mixture between static and dynamic libs is, I suppose, also possible, but I have never tried.

Thus, you don't need Intel compiler /Qipp options. Sorry for the long post. :))

Regards,
Sergey 

[SergeyKostrov]

>>...Let me bescribe the required steps. Look first at the conditional compilation constructions... Sergey, Thank you for very good explanations. However, Jan has runtime problem(s) and he has no any compilation or linker errors, right? Jan, When you changed settings to VC++ Compiler with Plattform Toolset of VS2008 it is possible that new set of macros / defines and search paths are set and that is why IPP DLLs can not be found. I understood that you can successfully compile sources and link object modules / dynamic link libraries, correct? Please confirm and thank you.

[Sergey_K_Intel]

Hi,

This is not a probleml. This is how Windows behaves when running applications linked with dynamic llibraries. This can happen with any of numerous Windows applications if corresponding DLL will sonehow disappear from its usual location and there's nothing special for IPP in this.

Jan intentionally or unintentionally linked apllication with IPP dynamic libs and now suffers from this :)) I've explained how to build application binary with static IPP libraries and forget about "not found DLL" problem.

By the way, now we are thinking about if it worth continuing relases of dynamic IPP libraries. If there nothing helpful in DLLs why not to stop doing them?

Regards,
Sergey 

[Jan_W_1]

Hello,

Thanks for your detailed answers. In fact there really was one subproject in the project that I accidently linked to an ipp lib without the "_l" extension. I corrected that and now it works fine.

Thanks a lot.

[SergeyKostrov]

As the user confirmed the problem was related to some "wrong" library used in a project and the same case was with user petervk. >>...By the way, now we are thinking about if it worth continuing relases of dynamic IPP libraries. If there nothing helpful >>in DLLs why not to stop doing them? We already discussed that subject some time ago and I've explained that when application is linked with dynamic link libraries and uses IPP DLLs it allows to change CPU dispatching DLLs for different computer systems with different CPUs. An application stays the same and doesn't need to be re-compiled! You need to contact all IPP developers in order to conduct a survey before making such final decision. I really would like to express concerns regarding that and possibility of removing DLLs from IPP. This is a wrong direction and it will affect thousands of IPP library developers. Take into account that Intel MKL and TBB teams don't even consider it and if a couple of developers had / have some issues with IPP DLLs this is Not the reason to remove DLLs and to change everything to static linking. All major libraries used in the software industry, like MFC, Boost, QT, GTK, etc, provide both options ( that is, dynamic and static linking ) and it allows a developer to decide what solution works better for a project. You should think about a solution similar to MKL's Link Adviser instead, like IPP Link Adviser, and it is Not clear why it is Not done for so many years.