llvm dev - Mar 2017 - Linker error with XRay & GCC/libstdc++ 6.1

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170216/c8e810e8/attachment.html>

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

> 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

(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/e1231ae9/attachment.html>