IPP 8.0 OS X, where are the lib*_l.a files?

[IDZ_A_Intel]

With the lastest 8.0 IPP packaged with Composer XE 2013 SP1 (initial release and Update 1), the lib*_l.a versions of the libraries are missing.  Was this a mistake?

How does one link against the static libraries?  Linking against the non "*_l.a" versions (like "libippcore.a") links, but only as a stub to the *.dylib.  At runtime we fail to find the *.dylib and fail to launch.

ron

[Pavel_B_Intel]

Hi Ron,

In IPP 8.0 package structure was changed, please see ReleaseNotes.html:

What's New in Intel® IPP 8.0

• Substantial distribution package reconfiguration
• Main package changes
• Intel® IPP library "_l" and "_t" suffixes removed. A new OS native convention is now implemented: Windows* static libraries now have an "mt" suffix for both single and multi-threaded libraries.
• Threaded libraries are now moved into the "threaded" subfolder.

• Single-threaded Dlls are moved into the main package.
• Px/mx optimizations are returned back into the main package.
• Intel® IPP SPIRAL (ippGen) is moved into the main package.
• Separate package distributions
• Cryptography for Intel® IPP is moved into a separate package.
• Demo applications are moved into a separate package. 

So in IPP 8.0 you have libippi.a, libipps.a, libippcore.a, etc

Please note that multi-threaded libraries are in "threaded" subfolder with the same names. It should be easy to switch project to use single-threaded or multi-threaded version of libraries.

Pavel

[daven-hughes]

Could someone address Ron's second question?

How do you link to the static libs such that the code is embedded in the custom library rather than dispatched? (in OS X that is)

[Jeremy_C_]

Same problem here - no static libs in OS X, would appreciate a reply/fix from Intel ASAP!

[Ron_Green]

I asked around and got an answer.

OK, so the _l.a files are gone.  Here's how to statically link now using the non-_l.a files:

Use the .a files BUT there's a catch:  if you link like this:

gcc -o mytest mytest.c -lippi -lipps -lippcore

on OS X 10.9 the linker will link libippi libipps libippcore against the DYNAMIC libraries IF it finds them (which it will).  I haven't tried it, but I would HOPE that if you throw in -static that the linker would do the right thing and pull in the static .a files.  Anther way to get around this linker behaviour we have to link EXPLICITLY with the .a files thusly:

gcc -o mytest mytest.c   $IPPROOT/lib/libippi.a  $IPPROOT/lib/libipps.a  $IPPROOT/lib/libippcore.a

This overrides the linker's default behaviour wherein when it sees a simple -lippi to attempt to first link against a dynlib.   In any case, we have a way to link statically.

ron

[daven-hughes]

Linking the static libraries with their full path was the solution. The static keyword applies to all libraries (including ex. the stdc++ lib) which may be undesired. 

Thanks!

[jeremy_arthur]

You can also use -Wl to pass options to the linker

$gcc -o mytest mytest.c   -Wl,-Bstatic -L$IPPROOT/lib/intel64 -lippi -lipps -lippcore  -L/opt/intel/composerxe/lib/intel64 -limf -lsvml -lirc -Wl,-Bdynamic

-Wl,-Bstatic tells it to link the following libraries statically

-Wl,-Bdynamic tells it to link any other system libraries, like -lm, dynamically