Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
2452 Discussions

Mac install location conflicts with code signing

Williams__Russell
728 Views

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

0 Kudos
10 Replies
Vladimir_P_1234567890
728 Views

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
728 Views

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

Thanks very much!

Russell

 

Williams__Russell
728 Views

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
728 Views

the change should be in 4.3 update 6.

Williams__Russell
728 Views

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
728 Views

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
728 Views

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
Black Belt
728 Views

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
728 Views

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
Black Belt
728 Views

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

 

Reply