Static Linking Error - ippcore-7.1 Dependency

Static Linking Error - ippcore-7.1 Dependency

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.

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

Update:
If I turn off the option "Use Intel Optimized Headers" (Under Configuration Properties -> C / C++ -> Optimization [Intel C++]) the dependency is removed.
Could that be explained?

Thanks.

if it so, than it looks like the error in VS2010 integration. We need to check it on our side.

This has not been fixed in Intel Compiler 13.

Settting /Quse-intel-optimized-headers causes a dependency on the IPP "threaded DLL" libraries, no matter what the settings on the project properties such as IPP : Static Libraries. This is a major PITA, especially since there are so many funky things happening in IPP right now ( functions being removed, threaded libraries deprecated etc).

>>If I turn off the option "Use Intel Optimized Headers" (Under Configuration Properties -> C / C++ -> Optimization [Intel C++])
>>the dependency is removed. Could that be explained?

It is possible that in some header a #pragma comment(...) directive is used:
...
#pragma comment ( lib, "ippcore-7.1.lib" )
...
and that is why it creates the dependency.

Any update?

>>...Any update?

Could you provide a small test project ( for example with a call to one IPP function ) for VS 2005, VS 2008 or VS 2010 that reproduces the problem and I'll take a look at it.

>>...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 completed a verification and I have Not found any issues or problems when my test application was compiled with Intel Parallel Studio XE 2013 Update 2 ( VS 2008 Professional Edition ). Here are screenshoots:

[ IPP Dynamic Linking ]

[ IPP Static Linking ]

Adjuntos: 

Please Don't pay attention ( Ignore ) for an error with IESHIMS.DLL. This is an issue with the Windows 7 and it is Not related to IPP.

[ Test-case codes for Dynamic linking ]

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// IppTestApp.cpp
// icl.exe /MD /Qipp /Qipp-link:dynamic IppTestApp.cpp
/*
Note 1: IPP Library Codes:

e9 - AVX
m7 - SSE3
u8 - SSSE3
y8 - SSE4.1/4.2

Note 2: If Intel C++ compiler option /Qipp is Not used there are Linker errors:

LNK2019: unresolved external symbol ippsGetLibVersion referenced in function main
LNK1120: 1 unresolved externals

Note 3:
Compilation:
icl.exe /MD /Qipp /Qipp-link:dynamic IppTestApp.cpp
Execute:
IppTestApp.exe
Output:
Dynamic linking of IPP library
Library Name : ippSP AVX (e9)
Library Version : 7.1.1 (r37466)
Library Build Date: Sep 24 2012
Dependencies:
ippcore-7.1.dll
ipps-7.1.dll
ippse9-7.1.dll
*/

#include
#include

#pragma comment ( lib, "ippcore.lib" ) // When /Qipp-link:dynamic is used

int main( void )
{
ippInit(); // When /Qipp-link:dynamic is used

printf( "Dynamic linking of IPP library\n" );

const IppLibraryVersion *pLibVer = NULL;

pLibVer = ::ippsGetLibVersion();
printf( "Library Name : %s\n", pLibVer->Name );
printf( "Library Version : %s\n", pLibVer->Version );
printf( "Library Build Date: %s\n", pLibVer->BuildDate );

return ( int )0;
}

[ Test-case codes for Static linking ]

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

// icl.exe /MD /Qipp /Qipp-link:static IppTestApp.cpp
/*
Note 1: IPP Library Codes:

e9 - AVX
m7 - SSE3
u8 - SSSE3
y8 - SSE4.1/4.2

Note 2: If Intel C++ compiler option /Qipp is Not used there are Linker errors:

LNK2019: unresolved external symbol ippsGetLibVersion referenced in function main
LNK1120: 1 unresolved externals

Note 3:
Compilation:
icl.exe /MD /Qipp /Qipp-link:static IppTestApp.cpp
Execute:
IppTestApp.exe
Output:
Static linking of IPP library
Library Name : ippSP AVX (e9)
Library Version : 7.1.1 (r37466)
Library Build Date: Sep 24 2012
Dependencies:
No Any dependencies
*/

#include
#include

int main( void )
{
ippStaticInit(); // When /Qipp-link:static is used

printf( "Static linking of IPP library\n" );

const IppLibraryVersion *pLibVer = NULL;

pLibVer = ::ippsGetLibVersion();
printf( "Library Name : %s\n", pLibVer->Name );
printf( "Library Version : %s\n", pLibVer->Version );
printf( "Library Build Date: %s\n", pLibVer->BuildDate );

return ( int )0;
}

...
#include "stdio.h"
#include "ipp.h"
...

>>...Yet after compiling I still get dependency of 'ippcore-7.1' and only 'ippcore-7.1'.
>>
>>I use Intel Compiler for the compiling process...

I finally reproduced your issue with Visual Studio 2008 Professional Edition & Intel C++ compiler XE 2013 Update 2 & IPP 7.1.x. Once again, this is Not a bug and you need to verify that IPP related options are matching to each other (!):

VS -> Select Build Components -> Intel IPP -> Use IPP -> Shared DLL
and
/Qipp /Qipp-link:dynamic

See screenshoot: that demonstrates dependencies ( Not matching options ):

Adjuntos: 

AdjuntoTamaño
Descargar ippstaticlinking1.jpg187.25 KB

Part 2

>>>>...Yet after compiling I still get dependency of 'ippcore-7.1' and only 'ippcore-7.1'.
>>>>
>>>>I use Intel Compiler for the compiling process...
>>
>>I finally reproduced your issue with Visual Studio 2008 Professional Edition & Intel C++ compiler XE 2013 Update 2 & IPP 7.1.x.
>>Once again, this is Not a bug and you >>need to verify that IPP related options are matching to each other (!):

VS -> Select Build Components -> Intel IPP -> Use IPP -> Single-threaded Static Library
and
/Qipp /Qipp-link:static

See screenshoot: that demonstrates dependencies ( matching options ):

Adjuntos: 

AdjuntoTamaño
Descargar ippstaticlinking2.jpg149.36 KB

Part 1 will be shown later since it is moderated...

Just in case this is an example of configuration with Dynamic ( Shared ) IPP libraries:

VS -> Select Build Components -> Intel IPP -> Use IPP -> Shared DLL
and
/Qipp /Qipp-link:dynamic

A message to Intel IPP forum moderator: One of my post is still Not Shown and please approve it. Thanks.

With regards to this thread. 

I have absolutely no issues with static vs. dynamic IPP as long as I do not use the use optimized intel headers option. As long as "use optimized intel headers" is off, the IPP link options works as designed.

>>...I have absolutely no issues with static vs. dynamic IPP as long as I do not use the use optimized intel headers option...

What happens when you turn that option On?

If I turn that option on, then the final EXE will depend on the dynamic IPP DLLs no matter what the IPP linking option -  assuming the code contains some mathematical function that is diverted to IPP via some header magic in the intel math headers.

>>...If I turn that option on, then the final EXE will depend on the dynamic IPP DLLs no matter what the IPP linking option...

It is Not clear for me how IPP headers could be related to Intel Optimized headers ( the latter ones are located in ( InstallDir )\Composer XE 20xx\Compiler\Include folder ).

Sergey - 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. The linker emits errors:

1>xilink : warning #10006: ignoring unknown option '/Qipp'
1>xilink : warning #10006: ignoring unknown option '/Qipp-link:static'

The resulting program "can't start because ippcore-7.1.dll is missing from your system." Unfortunately, even disabling the use of the Intel Optimized Headers does not enable any of our applications to run, even though the "Use IPP" option is set to "Single-threaded Static Library". Compiling the same code with Intel Studio XE 2011 and Visual Studio 2010 successfully creates executables that are statically linked against the IPP libraries.

This is a bug with Studio XE 2013 and Visual Studio 2012. We no longer have VS 2008 installed, so I cannot say whether VS2012 is required to trigger the bug with static linking. It is, however, sufficient. Also note that executables compiled with the debug libraries also are linked against the IPP dll's irrespective of whether static linking is used.

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,

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

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

Quote:

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.

Quote:

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.

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.

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.

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.

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

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. 

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.

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

#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

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 

Regards, Sergey

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

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 

Regards, Sergey

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.

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.

Deje un comentario

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