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

Wed Mar 8 13:15:39 PST 2017

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.

On Wed, Mar 8, 2017 at 10:10 AM David Blaikie <dblaikie at gmail.com> wrote:

> (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
>
> On Tue, Feb 21, 2017 at 9:39 AM Dean Michael Berris <dean.berris at gmail.com>
> wrote:
>
>
> > On 16 Feb 2017, at 13:41, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > 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()'
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170308/87d047c9/attachment-0001.html>