Heads up: With Composer XE 2013 sp1, Intel shipped two versions of the tbb libraries: one set linked to libstdc++ (the older C++0x gnu library), another linked to libc++ (the newer, C++11-compliant, LLVM library). They're incorrectly identified by the directory in which they're installed, and if you use the wrong one, the result is that any use of std::runtime_error may crash in the class destructor — whether or not you even throw the exception. The tbb problem:
/opt/intel/tbb/lib/*.dylib contains the libraries linked to libc++
/opt/intel/tbb/lib/libc++/*.dylib contains the libraries linked to libstdc++
But it's an Apple bug that it matters. Per https://developer.apple.com/library/mac/technotes/tn2185/_index.html#//a...
in the section titled "Which std C++ symbols are set in stone, and which aren't (ABI issues)", this issue is specifically addressed, and std::runtime_error is supposed to be ABI compatible across runtime changes. The list of C++ classes that are supposed to be ABI compatible is chosen because failure to make them compatible requires all the dynamic libraries and plugins in an app to be upgraded simultaneously, whether or not they ever explicitly pass those classes across the library boundaries. For example, merely linking with the wrong version of tbb can cause any use of std::runtime_error in your program to abort in its destructor.
That document also describes how they use versioning to allow ABI changes in other classes across library versions without forcing a lock-step upgrade for all libraries and plugins in an app