search for: xray_buffer_queu

On Sat, 3 Jun 2017 16:04:57 -0700 Tim Northover <t.p.northover at gmail.com> wrote: [snip] > I think you should be able to fix it by changing the > compiler-rt/lib/xray/test/CMakeLists.txt. If you find the > "add_compiler_rt_test" call and move "-lstdc++" to the end, just after > "-lrt" it should work. Thanks, Tim. I don't see "-lrt":

...rojects/compiler-rt/lib/xray/tests/unit/XRayBufferQueueTest -Wl,-allow-shlib-undefined -m64 -lstdc++ -lm -lpthread -lpthread -L/home/hanzer/build/build_llvm/./lib/clang/4.0.0/lib/linux -lclang_rt.xray-fdr-x86_64 /home/hanzer/build/build_llvm/./lib/clang/4.0.0/lib/linux/libclang_rt.xray-fdr-x86_64.a(xray_buffer_queue.cc.o): In function `std::make_error_code(std::errc)': /opt/rh/devtoolset-6/root/usr/include/c++/6.2.1/system_error:197: undefined reference to `std::_V2::generic_category()' /home/hanzer/build/build_llvm/./lib/clang/4.0.0/lib/linux/libclang_rt.xray-fdr-x86_64.a(xray_buffer_queue.cc.o): In...

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

...lude <system_error> > 1 #include <thread> > 2 #include <tuple> > 1 #include <unordered_map> > 1 #include <unordered_set> > 3 #include <utility> > I think the biggest part is containers, and they are mostly > in ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > dependencies without buffer queue and fdr logging: > ...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type > f|egrep -v 'tests|buffer|fdr'` | sort | uniq -c > 9 #include <atomic> > 4 #inclu...

...> 1 #include <thread> > > 2 #include <tuple> > > 1 #include <unordered_map> > > 1 #include <unordered_set> > > 3 #include <utility> > > I think the biggest part is containers, and they are mostly in > ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > Yes, buffer_queue can definitely live without using system_error, > unordered_map, and unordered_set. It might make it a bit more complex (we'd > need to implement a correct and fairly efficient hash set) but if it means > the deployment model is...

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

...> 1 #include <thread> > > 2 #include <tuple> > > 1 #include <unordered_map> > > 1 #include <unordered_set> > > 3 #include <utility> > > I think the biggest part is containers, and they are mostly in > ./xray_buffer_queue.h and ./xray_fdr_logging.cc. > > Yes, buffer_queue can definitely live without using system_error, > unordered_map, and unordered_set. It might make it a bit more complex (we'd > need to implement a correct and fairly efficient hash set) but if it means > the deployment model is...