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 make sure to not nuke it the next time. I guess I thought the detailed error message would be enough. I didn't build again, but I did configure with the settings posted yesterday, and there's a warning which I'm unsure how to interpret and if it's a concern: --- CMake Warning at tools/lldb/cmake/modules/LLDBConfig.cmake:409 (message): You appear to be linking to libstdc++ version lesser than 4.9 without exceptions enabled. These versions of the library have an issue, which causes occasional lldb crashes. See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656> for details. Possible courses of action are: - use libstdc++ version 4.9 or newer - use libc++ (via LLVM_ENABLE_LIBCXX) - enable exceptions (via LLVM_ENABLE_EH) - ignore this warning and accept occasional instability Call Stack (most recent call first): tools/lldb/CMakeLists.txt:4 (include) --- libstdc++ is 6.2.1 so the CMake check seems wrong. This prompted me to use -libstd=libc++ and -DLLVM_ENABLE_LIBCXX=ON, but for some reason Arch Linux packages llvm and clang in version 3.9.0 but libc++ in 3.8.0, so I skipped it. Unless the above libstdc++ warning is a problem, I will build and report back when done.
On Wed, Dec 21, 2016 at 9:00 AM, Carsten Mattner <carstenmattner at gmail.com> wrote:> 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 make sure to not nuke it the next time. I guess I thought the detailed > error message would be enough. > > I didn't build again, but I did configure with the settings posted > yesterday, > and there's a warning which I'm unsure how to interpret and if it's a > concern: > > --- > CMake Warning at tools/lldb/cmake/modules/LLDBConfig.cmake:409 (message): > You appear to be linking to libstdc++ version lesser than 4.9 without > exceptions enabled. These versions of the library have an issue, which > causes occasional lldb crashes. See > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656> for details. > Possible > courses of action are: > > - use libstdc++ version 4.9 or newer > > - use libc++ (via LLVM_ENABLE_LIBCXX) > > - enable exceptions (via LLVM_ENABLE_EH) > > - ignore this warning and accept occasional instability > Call Stack (most recent call first): > tools/lldb/CMakeLists.txt:4 (include) > --- > > libstdc++ is 6.2.1 so the CMake check seems wrong. >Or maybe it is picking up a different libstdc++ from somewhere else on your system? Here's the check from the cmake file: # There doesn't seem to be an easy way to check the library version. Instead, we rely 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 llvm and clang in version 3.9.0 > but libc++ in 3.8.0, so I skipped it. > > Unless the above libstdc++ warning is a problem, I will build and report > back when done. >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/84e621ff/attachment.html>
On Wed, Dec 21, 2016 at 6:10 PM, Teresa Johnson <tejohnson at google.com> wrote:> Or maybe it is picking up a different libstdc++ from somewhere else on your > system? > Here's the check from the cmake file: > > # There doesn't seem to be an easy way to check the library version. Instead, > # we rely 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; }"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 because ideally I want to do it that way, and it's a goal for a future default build config of llvm as discussed recently here, I'd prefer to build and then use the in-tree libc++. But it doesn't seem like -DLLVM_ENABLE_LIBCXX has that effect. Shouldn't it or if not why can't it? I would certainly welcome and find natural that the in-tree libc++ is used when LLVM_ENABLE_LIBCXX=ON. The need for a pre-built and installed libc++ is less practical.