Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

can't build TBB with clang

Eric_S_1
Beginner
1,398 Views

Using tbb41_20130116oss and clang on Mac OS X with the following invocations

[bash]

$ make compiler=clang arch=ia32
$ make compiler=clang arch=intel64
[/bash]

The build fails and the output contains ...

[bash]

Undefined symbols for architecture <arch>:

"vtable for tbb::tbb_exception", referenced from:
-exported_symbol[s_list] command line option
[/bash]

If you also have set the following environment variables

[bash]

CFLAGS='-isysroot /path/to/Xcode_4.6.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6'
CXXFLAGS='-isysroot /path/to/Xcode_4.6.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6'
LDFLAGS='-isysroot /path/to/Xcode_4.6.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6'
OSX_CFLAGS='-isysroot /path/to/Xcode_4.6.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6'
OSX_LDFLAGS='-isysroot /path/to/Xcode_4.6.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6'

[/bash]

Then the output includes the helpful:

[bash]

ld: warning: target OS does not support re-exporting symbol std::runtime_error::~runtime_error() from /Volumes/doriangray/devtools/Xcode_4.6.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/libstdc++.dylib
[/bash]

Clang installed from Apple's command line tools installer of Jan-2013.

[bash]

$ clang -v
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
[/bash]

0 Kudos
13 Replies
RafSchietekat
Valued Contributor III
1,398 Views

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

0 Kudos
Eric_S_1
Beginner
1,398 Views

Which version of clang 4.1 did you find it worked with?  For me, it doesn't work with any of the Xcode command line tools for Lion that I tried, including:

[bash]

Apple clang version 3.1 (tags/Apple/clang-318.0.61)

Apple clang version 4.0 (tags/Apple/clang-421.0.57) 

Apple clang version 4.1 (tags/Apple/clang-421.11.65)

Apple clang version 4.1 (tags/Apple/clang-421.11.66)

[/bash]

0 Kudos
RafSchietekat
Valued Contributor III
1,398 Views

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.)

0 Kudos
Vladimir_P_1234567890
1,398 Views

yes, thanks. We are looking into this.

--Vladimir

0 Kudos
Vladimir_P_1234567890
1,398 Views

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

--Vladimir

0 Kudos
RafSchietekat
Valued Contributor III
1,397 Views

It still doesn't work for me.

0 Kudos
Christian_D_
Beginner
1,397 Views

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

0 Kudos
Christian_D_
Beginner
1,398 Views

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:

[bash]

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

[/bash]

0 Kudos
Vladimir_P_1234567890
1,398 Views

It looks that solution would be to remove the line 

[cpp]
__TBB_SYMBOL( _ZTVN3tbb13tbb_exceptionE )
[/cpp]

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

--Vladimir

0 Kudos
Christian_D_
Beginner
1,398 Views

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?

0 Kudos
RafSchietekat
Valued Contributor III
1,398 Views

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?

0 Kudos
Vladimir_P_1234567890
1,398 Views

We can answer after further testing

0 Kudos
RafSchietekat
Valued Contributor III
1,398 Views

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).

0 Kudos
Reply