<div dir="ltr">(Kostya - it looks like this is true for the Sanitizers too - the library (I took sanitizer_libc.cc as an example) is built with the host compiler, then the unit test is compiler using just-built Clang and linked using just-built Clang. That seems like it could be a problem when those two compilers aren't using the same libraries/headers/etc?)<br><br>I think what might be happening is that libxray is being built with the host compiler, but the unit test is being linked with the just-built compiler? Is that possibly the case?<br><br>I'll keep looking into it to see if that's the case. <div><br>Yep, confirmed (see quoted build lines at the end of the email)<br><br>This is problematic because they're fundamentally different compilers with different include paths, link libraries, etc. <br><br>(in my case in particular - I have GCC 6.* installed in ~/install/* - if I use that GCC (or my clang release compiler installed alongside it) I get GCC 6.* headers and libs, but then that mismatches with the just-built Clang which doesn't find any of those headers/libs, but instead finds my system headers/libs - total ABI mismatch)<br><br>xray_buffer_queue.cc is built like this:<br> /usr/local/google/home/blaikie/install/bin/g++-6.3   -DLLVM_BUILD_GLOBAL_ISEL -DXRAY_HAS_EXCEPTIONS=1 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/xray -I/usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/lib/xray -Iinclude -I/usr/local/google/home/blaikie/dev/llvm/src/include -I/usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/lib/xray/.. -I/usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/lib/xray/../../include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -Wall -std=c++11 -Wno-unused-parameter -g    -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fvisibility-inlines-hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -MMD -MT projects/compiler-rt/lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_buffer_queue.cc.o -MF projects/compiler-rt/lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_buffer_queue.cc.o.d -o projects/compiler-rt/lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_buffer_queue.cc.o -c /usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/lib/xray/xray_buffer_queue.cc<br><br>but the test case is built like:<br>/usr/local/google/home/blaikie/dev/llvm/build/clang/experiment/./bin/clang -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -Wall -std=c++11 -Wno-unused-parameter -Wno-unknown-warning-option -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fvisibility-inlines-hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0 -I/usr/local/google/home/blaikie/dev/llvm/src/utils/unittest/googletest/include -I/usr/local/google/home/blaikie/dev/llvm/src/utils/unittest/googletest -I/usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/include -I/usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/lib/xray -I/usr/local/google/home/blaikie/dev/llvm/src/projects/compiler-rt/lib -m64 -c -o fdr_logging_test.cc.x86_64.o /mnt/fast/dev/llvm/src/projects/compiler-rt/lib/xray/tests/unit/fdr_logging_test.cc<br><br>and linked like:<br>/usr/local/google/home/blaikie/dev/llvm/build/clang/experiment/./bin/clang fdr_logging_test.cc.x86_64.o xray_unit_test_main.cc.x86_64.o gtest-all.cc.x86_64.o -o /usr/local/google/home/blaikie/dev/llvm/build/clang/experiment/projects/compiler-rt/lib/xray/tests/unit/XRayFDRLoggingTest-x86_64 -Wl,-allow-shlib-undefined -m64 -lstdc++ -lm -lpthread -lpthread -L/usr/local/google/home/blaikie/dev/llvm/build/clang/experiment/./lib/clang/5.0.0/lib/linux -lclang_rt.xray-x86_64 -latomic -ldl -lrt<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 21, 2017 at 9:39 AM Dean Michael Berris <<a href="mailto:dean.berris@gmail.com">dean.berris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On 16 Feb 2017, at 13:41, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Dean,<br class="gmail_msg">
><br class="gmail_msg">
> Wondering if you've seen anything like this:<br class="gmail_msg">
><br class="gmail_msg">
> /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/projects/compiler-rt/lib/xray/tests/unit && /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/./bin/clang fdr_logging_test.cc.x86_64.o xray_unit_test_main.cc.x86_64.o gtest-all.cc.x86_64.o -o /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/projects/compiler-rt/lib/xray/tests/unit/XRayFDRLoggingTest-x86_64 -Wl,-allow-shlib-undefined -m64 -lstdc++ -lm -lpthread -lpthread -L/usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/./lib/clang/5.0.0/lib/linux -lclang_rt.xray-x86_64 -latomic -ldl -lrt<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:197: error: undefined reference to 'std::_V2::generic_category()'<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:197: error: undefined reference to 'std::_V2::generic_category()'<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:141: error: undefined reference to 'std::_V2::system_category()'<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:141: error: undefined reference to 'std::_V2::system_category()'<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:197: error: undefined reference to 'std::_V2::generic_category()'<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:141: error: undefined reference to 'std::_V2::system_category()'<br class="gmail_msg">
> /usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/system_error:197: error: undefined reference to 'std::_V2::generic_category()'<br class="gmail_msg">
<br class="gmail_msg">
Interesting -- no, I haven't seen this before. :/<br class="gmail_msg">
<br class="gmail_msg">
We're using std::error_code and std::make_error_code(...), which should be defined by the standard library. I'm not sure what's special or what's changed with libstdc++ 6.1.<br class="gmail_msg">
<br class="gmail_msg">
I suspect XRay built with libc++ would require different symbols, (I don't know where std::_V2::... would be defined, whether that's an inline namespace in libc++ or in libstdc++) and therefore won't link properly with libstdc++. At least that's my initial theory here based on the error.<br class="gmail_msg">
<br class="gmail_msg">
Probably a configuration issue on the compiler-rt side, to make it use libstdc++ instead of libc++ when building the runtimes?<br class="gmail_msg">
<br class="gmail_msg">
-- Dean<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>