Due to the security enhancements in Mac OS 10.11 El Capitan, I am being forced to discontinue using the DYLD_LIBRARY_PATH environment variable to find dynamic libraries, and to use install_name_tool instead, as described in the Intel Developer article Application Configuration for Dynamic Libraries - however I am finding that doing so breaks the Intel code signature, which in turn disables the display of symbols in Xcode Instruments. Xcode also crashes randomly when debugging code that loads libraries modified in that way.
First, I can verify that a library such as lib/libifcore.dylib is signed by Intel:
% codesign --verify --verbose lib/libifcore.dylib lib/libifcore.dylib: valid on disk lib/libifcore.dylib: satisfies its Designated Requirement
Then I use install_name_tool to specify that the library itself, as well as the other Intel Fortran dynamic libraries it needs, can be found in one of the run path directories I specify for my executable:
% install_name_tool -id @rpath/libifcore.dylib lib/libifcore.dylib % install_name_tool -change libifcore.dylib @rpath/libifcore.dylib lib/libifcore.dylib % install_name_tool -change libimf.dylib @rpath/libimf.dylib lib/libifcore.dylib % install_name_tool -change libintlc.dylib @rpath/libintlc.dylib lib/libifcore.dylib % install_name_tool -change libsvml.dylib @rpath/libsvml.dylib lib/libifcore.dylib
However, at this point the code signature is now invalid:
% codesign --verify --verbose lib/libifcore.dylib lib/libifcore.dylib: invalid signature (code or signature have been modified) In architecture: x86_64
We'll look into this and do whatever seems appropriate. Chasing after Apple's constant shifting ground is getting to be a chore. (And, unfortunately, Microsoft is starting to break things in Visual Studio as often as Apple does in Xcode. I wish the imitation went the other way.)
The developers tell me that they did add @rpath to the dylibs for the 2016 Update 2 release. Which version are you using?
It appears we have been using 2016 Update 1. We downloaded Update 2 and I checked the .dylibs with 'otool -L', 'codesign --verify', and 'spctl', and it looks like they all use '@rpath' and are properly signed. So we will aim to upgrade as soon as we can run through our usual validation tests and with any luck that will resolve the issue!