search for: lldb_using_libstdcxx_4_9

...et<int> s = std::set<int>(std::allocator<int>()); > int main() { return 0; }" I cannot make g++ 6.2.1 fail to build the test snippet with or without the archlinux-default/custom CXXFLAGS and LDFLAGS. Time to find the real error and what's happening. > LLDB_USING_LIBSTDCXX_4_9) > > So the version check isn't precise, but unless libstdc++ 6.2.1 doesn't have this > interface available, which seems unlikely, something else is going wrong. That seems risky to ignore then. I guess I'll postpone the rebuild until this can be resolved/explained. Also beca...

...on the # fact that std::set did not have the allocator constructor available until version 4.9 check_cxx_source_compiles(" #include <set> std::set<int> s = std::set<int>(std::allocator<int>()); int main() { return 0; }" LLDB_USING_LIBSTDCXX_4_9) So the version check isn't precise, but unless libstdc++ 6.2.1 doesn't have this interface available, which seems unlikely, something else is going wrong. Teresa > > This prompted me to use -libstd=libc++ and -DLLVM_ENABLE_LIBCXX=ON, > but for some reason Arch Linux packages l...

...(std::allocator<int>()); > > int main() { return 0; }" > > I cannot make g++ 6.2.1 fail to build the test snippet with > or without the archlinux-default/custom CXXFLAGS and LDFLAGS. > > Time to find the real error and what's happening. > > > LLDB_USING_LIBSTDCXX_4_9) > > > > So the version check isn't precise, but unless libstdc++ 6.2.1 doesn't > have this > > interface available, which seems unlikely, something else is going wrong. > > That seems risky to ignore then. I guess I'll postpone the rebuild until > this &gt...

On Wed, Dec 21, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> wrote: > I think you can get this via "ninja -t commands bin/lldb-argdumper" > (this will give you a lot of output, all of the compilation commands > used to build that target). Or redo the build with -v to be sure. Unfortunately the old build tree is gone for space reclaim reasons. Sorry, I'll

Hello, Le 12/12/2016 à 18:29, Hans Wennborg a écrit : > +Sylvestre who knows about these things. > > On Thu, Dec 8, 2016 at 2:24 AM, Kris van Rens via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> L.S., >> >> I'm currently in the process of creating Debian packages for >> clang/llvm release 3.9.0. For this I'm using the steps as explained on

Trying to run a self host "ninja check-clang" with ASan enabled I hit a /lot/ of errors like this (strangely I hit none of these in check-llvm, only in check-clang): Any ideas? ==10525==ERROR: AddressSanitizer failed to deallocate 0x10800 (67584) bytes at address 0x631000014800 ==10525==AddressSanitizer CHECK failed:

...IES LIBXML2_LIBRARIES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: LIBXML2_XMLLINT_EXECUTABLE LIBXML2_XMLLINT_EXECUTABLE-ADVANCED:INTERNAL=1 //Test LINKER_SUPPORTS_COLOR_DIAGNOSTICS LINKER_SUPPORTS_COLOR_DIAGNOSTICS:INTERNAL= //Have symbol __GLIBCXX__ LLDB_USING_LIBSTDCXX:INTERNAL=1 //Test LLDB_USING_LIBSTDCXX_4_9 LLDB_USING_LIBSTDCXX_4_9:INTERNAL=1 //For Visual Studio 2013, manually copy natvis files to Documents\Visual // Studio 2013\Visualizers LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION:INTERNAL=FALSE //ADVANCED property for variable: LLVM_BUILD_INSTRUMENTED LLVM_BUILD_INSTRUMENTED-ADVANCED:INTERNAL=1 //ADVA...