- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that will work for us. Please let us know which version that change is in.
Thanks very much!
Russell
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the change should be in 4.3 update 6.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page