Static linking of IPP 8.1 in Linux

[eos_pengwern]

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?

[Pavel_B_Intel1 · Accepted solution]

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

[eos_pengwern]

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.

[Pavel_B_Intel1]

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

Pavel