Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Using install_name_tool on ifort libraries breaks Xcode Instruments

Mark_T_2
Beginner
714 Views

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?

 

 

 

0 Kudos
5 Replies
Steven_L_Intel1
Employee
714 Views

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.)

0 Kudos
Steven_L_Intel1
Employee
714 Views

Escalated as issue DPD200409654. I will let you know of any new information we learn.

0 Kudos
Steven_L_Intel1
Employee
714 Views

The developers tell me that they did add @rpath to the dylibs for the 2016 Update 2 release. Which version are you using?

0 Kudos
Steven_L_Intel1
Employee
714 Views

We believe that this was already fixed in Update 2.

0 Kudos
Mark_T_2
Beginner
714 Views

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!

0 Kudos
Reply