Mac install location conflicts with code signing

[Williams__Russell]

tbb dylibs on the Mac are built with an install name path (otool -D) of "libtbb.dylib" (and similar names for all the other tbb libraries), which means that if you link with them as-is and place it inside an app package in the Apple-recommended location, they won't be found and you'll die on launch with

dyld: Library not loaded: libtbb_debug.dylib

  Referenced from: /Users/williams/photoshop/main/photoshop/Targets/Debug_x86_64/Adobe Photoshop CC 2015.app/Contents/MacOS/Adobe Photoshop CC 2015

  Reason: image not found

The correct install name path is @executable_path/../Frameworks/libtbb.dylib. For the last few releases we've been fixing this by copying the tbb dlls into our build folders and running

install_name_tool -id "@executable_path/../Frameworks/libtbb.dylib" libtbb.dylib

etc. on them. We can then link against them and copy them into our app package in the Apple-designated frameworks directory. But now that Intel is signing the binaries (which is a good thing), modifying them with install_name_tool invalidates the signatures. I'd like to request that Intel either build the libraries with an install name path for the standard Apple install location, or give us another workaround that avoids invalidating the signatures.

Russell Williams

Photoshop architect

[Vladimir_P_1234567890]

Hello Russel,

we are aware of the issue and looking how to address it and provide signed binaries with the most usable scenario value. Current idea is to setup install_name field to "@rpath/libtbb.dylib" value. Will such scenario work for you?

So far I can propose the following workaround:

my_machine:tbb user# install_name_tool -id @executable_path/../Frameworks/libtbb.dylib libtbb.dylib
my_machine:tbb user# codesign -vv libtbb.dylib                                                                                                                                                                                   
libtbb.dylib: invalid signature (code or signature have been modified)
In architecture: x86_64
my_machine:tbb user# codesign -f -s - libtbb.dylib                                                                                                                                                                                 
libtbb.dylib: replacing existing signature
my_machine:tbb user# codesign -vv libtbb.dylib 
libtbb.dylib: valid on disk
libtbb.dylib: satisfies its Designated Requirement

--Vladimir

[Williams__Russell]

Yes, that will work for us. Please let us know which version that change is in.

Thanks very much!

Russell

[Williams__Russell]

Just a quick note for anyone else running into this problem: that requires that your app has to be built with an rpath of @executable_path/../Frameworks — which it should be already.

[Vladimir_P_1234567890]

the change should be in 4.3 update 6.

[Williams__Russell]

Great -- thanks!. BTW, I think TBB is a fabulous tool for parallelization: provides lots of abstractions at various levels in a useful way, it's fast, reliable, and in most cases it's easy to see how to get good performance out of a particular abstraction.

[Williams__Russell]

I see that composer xe 2015 sp 3 has tbb 4.3 update 5. Will we need Composer XE 2015 sp 4 to get tbb 4.3 update 6? And do you have an approximate date for tbb 4.3 update 6?

Thanks.

[Vladimir_P_1234567890]

It was released last Thursday. This is a standalone update. Don't you see it in the registration center online or Intel Software Manager on the machine?

[RafSchietekat]

New problem after upgrade to El Capitan ([...] abbreviation mine):

sh ../../build/test_launcher.sh  -l libtbbmalloc_proxy_debug.dylib ./test_malloc_overload.exe 
dyld: Library not loaded: @rpath/libtbbmalloc_debug.dylib
  Referenced from: /[...]/tbb44_20150728oss.git/build/macos_intel64_clang_cc4.2.1_os10.11.1_debug/libtbbmalloc_proxy_debug.dylib
  Reason: image not found
../../build/test_launcher.sh: line 83: 10168 Trace/BPT trap: 5       $run_prefix $*
./test_malloc_overload.exe: exited with error 133

Allegedly it's something with the new System Integrity Protection, but I have not investigated further.

(Added) Most test programs still work, but none of the examples!

[Vladimir_P_1234567890]

Hello,

Yes, this is related to SIP. It drops an environemnt for forked shells. Test launchers should be fixed in coming updates. For examples we have not found an elegant way to fit a solution in current makefiles. So far a workaround for examples is

run_cmd="DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH" make <args>

BTW Xcode examples projects should work.

--Vladimir

[RafSchietekat]

I verified that the following works (with abbreviated prompt):

$ export DYLD_LIBRARY_PATH=`pwd`/build/macos_intel64_clang_cc4.2.1_os10.11.1_release
$ run_cmd="DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH" make examples