topic It isn't a trick, it is in Intel® Integrated Performance Primitives

Static linking of IPP 8.1 in Linux

eos_pengwern — Wed, 28 May 2014 12:57:58 GMT

I've been using the IPP successfully on Windows for a long time, but am now trying to port my application over to Linux. My project architecture requires that I link the IPP libraries statically into my own code, which itself is compiled as a Shared Library.

In Windows, and in Linux up to IPP 7.0, the names of the static and dynamically-linked versions of the libraries differed, with the static versions having filenames ending in 'mt' (in Windows) and '_l' (in Linux). Therefore, if I'd wanted to link the static V7.0 libraries then it looks like my makefile would have needed to contain the line:

IPPLIB = -lippac_l -lippdc_l -lippcc_l -lippcv_l etc.

However, it appears that in IPP 8.0 onwards the distinction in names has been abolished (at least in Linux), and so if I list the contents of the /opt/intel/composer_xe_2013_sp1/ipp/lib/intel64 directory I see:

libippac.a libippac.so libippac.so.8.1 libippace9.so etc.

It seems obvious enough that the .a files are the static libraries and the various .so files are the shared libraries for various different processors. However, I can't work out how to access the static libraries. If I do the naive thing, and put this line into my makefile:

IPPLIB = -lippac -lippdc -lippcc -lippcv etc.

...then the compilation completes cleanly, but at runtime I get bombarded with messages to the effect of "lipippac.so not found" so the compiler obviously thinks that it actually linked the shared versions. If I try to make things more explicit, with:

IPPLIB = -lippac.a -lippdc.a -lippcc.a -lippcv.a etc.

...then this simply fails to compile, the first error message (of a large number) being "cannot find -lippi.a".

So, what is the correct syntax for linking static IPP libraries into my own shared library?

You in IPP 8.0 we changed

Pavel_B_Intel1 — Thu, 29 May 2014 06:17:00 GMT

You in IPP 8.0 we changed libraries name convention to native OS, so you have 2 options:

1) use "-static" option:
(man ld):
-static
Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are
supported. The different variants of this option are for compatibility with various systems. You may use
this option multiple times on the command line: it affects library searching for -l options which follow it.
This option also implies --unresolved-symbols=report-all.

2) if you use static libraries only - link the libraries by using full path and full library name, for example $IPPROOT/lib/ia32/libippac.a

from my point of view option 2 is more better because you can mix linking: link with IPP static libraries and with shared runtime libraries.

Pavel

Thank you, that seems to do

eos_pengwern — Thu, 29 May 2014 11:35:29 GMT

Thank you, that seems to do the trick. For comparison, I looked at the MKL link-line advisor to see how the same issue is handled there, and the pattern is just as you've described.

It isn't a trick, it is

Pavel_B_Intel1 — Thu, 29 May 2014 11:38:00 GMT

It isn't a trick, it is native behaviour of Linux link tool to link shared libraries at the first priority.

Pavel