Libraries identified with wrong c++ library, std::runtime_error crash results

[Williams__Russell]

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#//apple_ref/doc/uid/DTS10004200-CH1-SECTION16

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

[Vladimir_P_1234567890]

Indeed!

We will fix this. 

Thanks for the report,
--Vladimir

[RafSchietekat]

Question for Russell: as a separate issue, would it be useful to present TBB as a framework (headers and libraries bundled together), which seems to be the Apple way? There are no auxiliary files, so the answer isn't clearly yes, but it might save a few configuration steps and look more familiar to the intended audience (I tend to build from source, myself).

(Added) I tried to cook up a framework, but without success so far.

[Williams__Russell]

A framework is somewhat preferable, just because it *is* standard. Apple has a history of doing things that make you sorry you weren't using standard mechanisms, so you never know what might happen next year. But we've never run across a situation where we were frustrated by the non-Framework nature of TBB. The arguments against change are:

1. It's working now, the current scheme isn't a big pain, Frameworks don't buy us much in this case, and change always carries risk.

2. You can't do the integrates or checkins on a Windows platform because of the symlinks. (doesn't affect us since we have lots of other third-party frameworks that require integration).

Summary: yes, Frameworks are better, but as an issue it's well below our threshold of significance.

Russell

[RafSchietekat]

That makes me feel less guilty about giving up so easily. :-)