IPPv8 library coexistence with older libraries in same address space

IPPv8 library coexistence with older libraries in same address space


I use IPP within a music production plugin (see here). These types of executables are provided as dynamic libraries that are loaded by host applications (e.g. this or this as examples). I have some signal processing functions compiled into my binaries, and all is good. Except in a few cases where the host applications also use IPP, and they use a different version to me. For years I've used IPP v6, a host vendor got in touch saying they were using IPP v8 and that my plugin crashed within their host. So I updated my plugin to IPP v8, and that fixed the issue, and now my plugin crashes in other hosts (which I know use IPP because I've looked into their binaries and can see the IPP symbols and the date of their binary suggests that they probably are not using IPPv8). Crashes can be on IPP functions, or seemingly anywhere else.

This problem only happens on my OS X builds (I also have a Windows version).

So, I suspect some kind of symbol conflict. I have run to the limit of my understanding here, but what I assume is happening is something like I am loading IPP code into the address space of a host that also uses the same IPP functions, but since they're a different version and now two or more of the same thing are loaded, there is some confusion as to which code to use as it's using the same names and I am calling their functions and they are calling mine, thing nasty goes wrong, and it crashes either then or somewhere down the line.

The only solution I can see is to somehow do some kind of name-spacing, where my IPP functions are actually called something else, so there is no chance of confusion. Can I do that? If so, how do I do that on OS X (I'm using XCode 5, IPP 8.0.0 update 1, llvm 5). Or is there another solution to this kind of thing?



7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Matt,

The only problem of co-existing of different IPP versions can be if you use function groups with state/struct/context/etc. These are functions like *GetSize, *Init, *Process.

For some function groups the content of internal structures could change from version to version and the function groups should be used strictly from a single IPP version.

For example,

ippGetSize<>(..., &size);         // GetSize from IPP of version X
pState = malloc(size);             // In previous IPP versions there were functions like ippAllocInit<> which are deprecated now
ippInit<>(pState);                   // Let Init function from IPP version X too
ipp<some processing function>(arg, arg, ..., pState);   // Problem if processing function is taken from IPP of version Y. 
// It may assume that pState structure is corresponding to IPP of version Y


Do you use the IPP functions (group of functions) like above?


Yes I do as I am using FFTs and resampling functions. 

Should I assume then I am correct in my guess that loading a plugin with IPP functions within it into the address space of a host with different IPP version functions will cause these kinds of issues as a plugin can 'see' the linked functions from the host and vice versa?

Given I am using IPP in a plugin and have no way to know if I am being loaded into a host that may be using IPP, and given that host could use any IPP version, what do you suggest I do to alleviate the problem?

Note, that this problem may appear only when both user app and plug-in use dynamic linking to IPP shared objects (shared libraries). If any of them uses static linking, the issue is resolved at link time.

Suppose, that the plug-in is linked to new IPP library statically. This means, that none of IPP calls from within plug-in will search for import symbols from any of (including old version) IPP dynamic libs. In this case there will be no conflict.

How your user applications and your plug-in is linked to IPP?


Yes I am fairly sure I am linking statically as the binaries work on a system without any IPP libraries. If you believe it not possible there can be any conflict between IPP versions within the same memory space I will need to devise a test case to try to illustrate my scenario. 

As long as dynamic address resolving is done on a base of import names only, there will be conflicts.

Even if you add run-time address fetches using "dlsym" in your plug-in, you can not guarantee, that user application - with dynamic linkage - will be getting the correct "old-IPP-version" function addresses  when conflicting shared objects (IPP version N and IPP N+1) are both available for dynamic loading.

P.S. Though, there could be the ways out. I am not good in Linux.


Problem resolved - I had the -flat_namespace option set in the 'other linker flags' and this seems to cause this issue.

Leave a Comment

Please sign in to add a comment. Not a member? Join today