can't build TBB with clang

can't build TBB with clang

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

$ make compiler=clang arch=ia32
$ make compiler=clang arch=intel64

The build fails and the output contains ...

Undefined symbols for architecture <arch>:
"vtable for tbb::tbb_exception", referenced from:
 -exported_symbol[s_list] command line option

If you also have set the following environment variables

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'

Then the output includes the helpful:

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

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

$ 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

14 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

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

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:

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)

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

附件: 

发表评论

登录添加评论。还不是成员?立即加入