I just verified that things worked with clang version 4.1, and then broke after updating to version 4.2.

Before and after the update:

[...]$ clang -v
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.1
Thread model: posix
[...]$ clang -v
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.1
Thread model: posix
[...]$ 

After the update (manual update from Xcode, now configured for automatic update) I started getting the error you mentioned. (I also had to add the second flag in "WARNING_SUPPRESS = -Wno-non-virtual-dtor -Wno-unused-private-field" at tbb41_20130116oss/build/macos.clang.inc:39. TBB team: please acknowledge. Building with g++ was not affected.)

yes, thanks. We are looking into this.

--Vladimir

As far as I understand the fix is available in update 3.

--Vladimir

It still doesn't work for me.

I confirm that the issue still persists with the most recent TBB version downloadable from the website and the newest clang version provided by Xcode (Apple LLVM version 4.2 (clang-425.0.28)) as well as a custom built LLVM with clang 3.2. However, with a custom built clang 3.1 everything compiles smoothly. Are there any plans to fix this or is this an issue of clang itself?

Any help would be appreciated...

Addendum: a build from the current SVN repository of clang 3.3 still shows the same problem. Only this time, the displayed symbol name is mangled:

Undefined symbols for architecture x86_64:
 "__ZTVN3tbb13tbb_exceptionE", referenced from:
 -exported_symbol[s_list] command line option

It looks that solution would be to remove the line 

__TBB_SYMBOL( _ZTVN3tbb13tbb_exceptionE )

from src/tbb/mac??-tbb-export.lst files for these compilers.:)

--Vladimir

Thank you, that indeed solves the problem. I'm wondering, is this just a temporary workaround or can this line be safely and permanently removed?

Works for me too.

While working on a contribution to get rid of a number of warnings (tbb41_20130314oss_src.tgz: release 4.1 update 3), I'm puzzled by the following (make compiler=clang clean all 2>&1 | grep warning | sort | uniq -c | sort -r | open -ef):

6 ../../src/test/harness_graph.h:123:28: warning: variable 'current_executors' is not needed and will not be emitted [-Wunneeded-internal-declaration]
2 ../../src/test/test_condition_variable.h:653:25: warning: variable 'err_count' is not needed and will not be emitted [-Wunneeded-internal-declaration]

(Edited first line after seeing next posting.)

(Edited list of warnings down to the problematic ones.)

(Added) Apparently it's also just a matter of adding "/*otherwise unused*/(void)err_count;" to test_tbb_condition_variable.cpp, and of adding "/*otherwise unused*/(void)current_executors;" to test_overwrite_node.cpp, test_source_node.cpp and test_write_once_node.cpp. Hmm, I thought that the compiler fences worked by being opaque to the compiler, so how can they still be functional as compiler fences if the compiler can see right through them?

We can answer after further testing

Silly me: those compiler fences were never invoked!

It's remarkable how Clang is doing control flow analysis even without optimisation... could this really be at negligible cost?

Alternatively, the following also works to keep the build log clean (but more verbose):

# -Wno-unneeded-internal-declaration to suppress warnings about current_executors in harness_graph.h and err_count in test_condition_variable.h
TEST_WARNING_KEY = -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-unneeded-internal-declaration

(Added) For other unused variables (as indicated in my contribution), instead of "/*otherwise unused*/(void)pad[0];", consider "#define __TBB_ATTRIBUTE_UNUSED __attribute__((unused))" (only for Clang: g++ issues "warning: ‘unused’ attribute ignored").

(Added) For my_index in private_server.cpp, it's probably better to only define it if AVOID_64K_ALIASING uses it.

(Added 2013-04-20) Added patch (more complete than the one already officially contributed).