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
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.
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
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.
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.
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?
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!
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.
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