Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
10 Views

Using install_name_tool on ifort libraries breaks Xcode Instruments

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
Highlighted
10 Views

We'll look into this and do

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

Retired 12/31/2016
0 Kudos
Highlighted
10 Views

Escalated as issue

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

Retired 12/31/2016
0 Kudos
Highlighted
10 Views

The developers tell me that

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

Retired 12/31/2016
0 Kudos
Highlighted
10 Views

We believe that this was

We believe that this was already fixed in Update 2.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
10 Views

It appears we have been 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!

0 Kudos