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
This has recently become a problem not just from a code security standpoint in general, but because Xcode Instruments is now apparently checking code signatures, and an invalid signature in any dynamic library used by my executable completely disables the display of any symbols in Instruments, and is also causing crashes in the Xcode debugger. I fear that Apple may decide at some point not to allow such executables to run at all. I feel that for maximum flexibility, Intel should be shipping code-signed Intel Fortran libraries that already use '@rpath' to specify where they can be found, either instead of, or in addition to, the ones that are currently shipping. I see that this is already being done for other Intel Products such as in this recent release of the OpenMP Runtime Library - how soon could we see a similar change to Intel Fortran?