[llvm-dev] Linker error with XRay & GCC/libstdc++ 6.1

[David Blaikie via llvm-dev]

Hi Dean,

Wondering if you've seen anything like this:

/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

/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()'

/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()'

/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()'

/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()'

/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()'

/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()'

/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()'

Sudhir Rana

[Stefan via llvm-dev]

Hey dudes,
I'm interested in contributing to the llvm project and adding support
for some PIC's, though I'm pretty newbie. Has anyone some suggestions on
how to get started (learning by doing...), I'm already reading carefully
a bit through the basic documentation and googled how to contribute, but
nevertheless (as long as an email is free of charge lol).

greetings,
gluttony
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Dean Michael Berris via llvm-dev]

Interesting -- no, I haven't seen this before. :/

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.

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.

Probably a configuration issue on the compiler-rt side, to make it use libstdc++ instead of libc++ when building the runtimes?

-- Dean

[David Blaikie via llvm-dev]

(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?)

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?

I'll keep looking into it to see if that's the case. 

Yep, confirmed (see quoted build lines at the end of the email)

This is problematic because they're fundamentally different compilers with different include paths, link libraries, etc. 

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

xray_buffer_queue.cc is built like this:
 /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

but the test case is built like:
/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

and linked like:
/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

[David Blaikie via llvm-dev]

Chatted with Chandler over lunch - seems like there's two problems here.
1) the use of C++ in the xray runtime (as-is, probably not good because the runtime may be built with a completely different C++ library than is linked into an executable using xray, so ABI mismatch and sadness)
2) the use of the host compiler when building compiler-rt (probably not good since we'd want clang's optimizations, etc - and if not, why are we spending ages building clang only to build the compiler-rt unit tests, etc)

I'll start two new/separate threads for these.