IPP 6 and libiomp5.dylib

[Robert_Bell]

Hi all,

So, after upgrading to IPP 6, I noticed an old IPP problem return. It seems that libiomp.dylib does not have the correct install path associated with it. This library is a dependent library forlibippcore.dylib andlibipps.dylib. (see the otool outputs below). The problem with this is that it then forces runtime searching via other means (such as with an environment variable). On Mac OS X, this has proved problematic with non-shell like programs (with shell programs, it is easy to set the environment). There have been various methods of injecting dynamic library paths into an application's environment, but many have been changed; some for security reasons (for example: environment.plist, LSEnvironment).

I have tried other means of fixing this, such as usinginstall_name_tool to try and change the path to the dependent libraries. For example:sudo install_name_tool -change libiomp5.dylib /opt/intel/Compiler/11.0/059/lib/libiomp5.dylib libippcore.dylib. But this causes different errors:Error at loading of ippSP library: No shared libraries were found in the Waterfall procedure.

I guess I have three questions:

1) Why are the dependent libraries not bundled into the /Library/Frameworks/Intel... as sym links like the others?

2) Why are the install names not in the dynamic library (-install_name build option)?

3) Lastly, how can I fix these libraries (using something like install_name_tool) to get them to work with executables etc that do not not want to rely on environment variable methods (not everyone launches from within xcode, or from the shell).

Note: I would rather use the dynamic libraries as recommended in the docs.

Note 2: I sent a similar note to the MKL list a while ago (their libraries always had the issue). I received a friendly note back saying the developers would look into it ... but after a number of releases, things were still the same with MKL. In fact, in that note, I commented on how well IPP version 5.3 worked.

IPP 5.3 worked perfectly in this regard. I could link to the dynamic libraries. No runtime errors. All paths were correct. It would be nice to return to that happy world! :-)

Thanks in advance for any help. And myapologiesif there is a simple solution and via myignorance, I have ignored it!

Robert.

Some links and outputs:http://www.codeshorts.ca/tag/osx/ (however, I must support Mac OS 10.4 ... so I cannot use rpath).

otool -L libippcore.dylib

libippcore.dylib:

/Library/Frameworks/Intel_IPP.framework/Libraries/libippcore-6.0.dylib (compatibility version 0.0.0, current version 0.0.0)

libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.6)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

otool -D libiomp5.dylib

libiomp5.dylib:

libiomp5.dylib

[Vladimir_Dudnik]

Hello,

thanks for reporting on the issue. We will let our experts to check what might be the problem

Regards,
Vladimir

[Robert_Bell]

Quoting - Vladimir Dudnik (Intel)

Hello,

thanks for reporting on the issue. We will let our experts to check what might be the problem

Regards,
Vladimir

For the moment, and for the interest of others in the Mac environment, I have wrapped the application code using a launcher and calls to LSOpenApplication (see below example). This seems to work reliably across all minor versions of 10.4 and 10.5. Clearly hard-coding theDYLD_LIBRARY_PATH path is not wonderful, but it's just an example. :-) Also, remember that if you are wrapping using a shell program target (which the user will double click on as well as launch from inside the terminal), the path passed to it will not always be the current directory ... you'll have to grab that from the "args". This only matters of course if the launcher is assuming that the actual app is living in the same directory.

If anyone as a reaction of "nooooooo ..." to this solution, please post. :-) It seems to me to be a bit more Apple-ish, and you can attach a nice GUI to it if you would like (you might even get a nice current working directory out of it too).

keys[0] = CFSTR("DYLD_LIBRARY_PATH");

values[0] = CFSTR("/opt/intel/Compiler/11.0/059/lib");

...

// Setup the application parameters.

LSApplicationParameters appParams;

appParams.version = 0;

appParams.flags = kLSLaunchDontAddToRecents | kLSLaunchDontSwitch | kLSLaunchAsync;

appParams.application = &ref;

appParams.asyncLaunchRefCon = NULL;

appParams.environment = env;

appParams.argv = NULL;

appParams.initialEvent = NULL;

err = LSOpenApplication(&appParams, NULL);

[Robert_Bell]

Hi all,

So I just checked the 064 version, and the problem still exists. There is a lot of chatter on this site with regard to this issue, and most directions point to using environment variables (which as I mentioned, does not help all of us in the Mac world), or static linking (which is not recommended).

May I ask why there are path entries to certain dylibs, but not others? With no path in the library for the dependentlibiomp5.dylib, the linker will not be able to pick it up, and having to support Mac OS 10.4, we are certain to fail at runtime unless we use environment variables (or I am completely off base ... feel free to let me know that. :-) ).Here again is the an example, this time with the 064 version (please see my previous post for how to fix it):

otool -L libipps.dylib

libipps.dylib:

/opt/intel/Compiler/11.0/064/Frameworks/ipp/Libraries/libipps-6.0.dylib (compatibility version 0.0.0, current version 0.0.0)

/opt/intel/Compiler/11.0/064/Frameworks/ipp/Libraries/libippcore-6.0.dylib (compatibility version 0.0.0, current version 0.0.0)

libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.6)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

ciel:Libraries bertie$ otool -L libippcore.dylib

I guess I would really like to know what your ETA is on this. We were hoping to make a full switch to IPP support on a product which is currently in beta testing, and it is causing us a good deal of configuration pain.

Thanks in advance,

Robert.

Quoting - Robert Bell

Hi all,

So, after upgrading to IPP 6, I noticed an old IPP problem return. It seems that libiomp.dylib does not have the correct install path associated with it. This library is a dependent library forlibippcore.dylib andlibipps.dylib. (see the otool outputs below). The problem with this is that it then forces runtime searching via other means (such as with an environment variable). On Mac OS X, this has proved problematic with non-shell like programs (with shell programs, it is easy to set the environment). There have been various methods of injecting dynamic library paths into an application's environment, but many have been changed; some for security reasons (for example: environment.plist, LSEnvironment).

I have tried other means of fixing this, such as usinginstall_name_tool to try and change the path to the dependent libraries. For example:sudo install_name_tool -change libiomp5.dylib /opt/intel/Compiler/11.0/059/lib/libiomp5.dylib libippcore.dylib. But this causes different errors:Error at loading of ippSP library: No shared libraries were found in the Waterfall procedure.

I guess I have three questions:

1) Why are the dependent libraries not bundled into the /Library/Frameworks/Intel... as sym links like the others?

2) Why are the install names not in the dynamic library (-install_name build option)?

3) Lastly, how can I fix these libraries (using something like install_name_tool) to get them to work with executables etc that do not not want to rely on environment variable methods (not everyone launches from within xcode, or from the shell).

Note: I would rather use the dynamic libraries as recommended in the docs.

Note 2: I sent a similar note to the MKL list a while ago (their libraries always had the issue). I received a friendly note back saying the developers would look into it ... but after a number of releases, things were still the same with MKL. In fact, in that note, I commented on how well IPP version 5.3 worked.

IPP 5.3 worked perfectly in this regard. I could link to the dynamic libraries. No runtime errors. All paths were correct. It would be nice to return to that happy world! :-)

Thanks in advance for any help. And myapologiesif there is a simple solution and via myignorance, I have ignored it!

Robert.

Some links and outputs:http://www.codeshorts.ca/tag/osx/ (however, I must support Mac OS 10.4 ... so I cannot use rpath).

otool -L libippcore.dylib

libippcore.dylib:

/Library/Frameworks/Intel_IPP.framework/Libraries/libippcore-6.0.dylib (compatibility version 0.0.0, current version 0.0.0)

libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.6)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

otool -D libiomp5.dylib

libiomp5.dylib:

libiomp5.dylib

[Albert_Stepanov]

Hi Robert,
As a workaround you can
1)# cd /Library/Frameworks/Intel_IPP.framework
2) # ./Versions/Current/tools/env/ippunbind.sh
3) # cp /opt/intel/Compiler/11.0/064/lib/libiomp5.dylib ./Libraries
4) # ./Versions/Current/tools/env/ippbind.sh
Note: in point 4 you can get "can't change id for libiomp5.dylib" but all IPP libraries will be bound.

Regards,

Albert

[Robert_Bell]

Thanks Lee.

The library we are using is ipps. I had actually used install_name_tool on this and ippcore, but then had gotten a further error loadingippSP. It looks as if it is doing a load internally of ippspx. However, not wanting to take the time to actually find that it was ippsx out of all the others, I had just stopped at that point. After your response, I decided to actually do it. Thus, using install_name_tool I can now destribute just iomp5, ippcore, ippspx, and ippcore.

I did notice that there is a redistribute library available for download with the compiler suite. Even though the compiler runtime is in this, none of the ipp stuff is. It seems that it would be really nice to have a redistribute package for Mac OS X that was a bit smarter, and could resolve these dependencies (such as by running the scripts you mentioned after user input). One might argue that one can make it work, but given the number of confused people, it seems like a good idea for the future.

Thanks,

Robert.

Quoting - lee_step

Hi Robert,
As a workaround you can
1)# cd /Library/Frameworks/Intel_IPP.framework
2) # ./Versions/Current/tools/env/ippunbind.sh
3) # cp /opt/intel/Compiler/11.0/064/lib/libiomp5.dylib ./Libraries
4) # ./Versions/Current/tools/env/ippbind.sh
Note: in point 4 you can get "can't change id for libiomp5.dylib" but all IPP libraries will be bound.

Regards,

Albert