So I’m trying to run a clean “ninja check-lldb” and I’m running into some difficulties with the libc++ pretty printer tests.
- They’re “unsupported” if my host compiler is gcc:
$ ninja check-lldb-api-functionalities-data-formatter-data-formatter-stl-libcxx
[2/3] Running lit suite …/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx
Testing Time: 1.57s
Looking at the logs (see other thread: perhaps those logs should actually be part of the test output - especially for buildbots where you’d have no ability to read separate log files): "
unittest2.case.SkipTest: could not find library matching ‘libc++’ in target a.out"
So, looks like it built with the just-built clang, but without libc++? (since libc++ isn’t built yet in this tree) - but the logs don’t show the commands that built the binary - should I be able to find that somewhere? It seems important for debugging exactly what’s under test, etc.
- Oh, but if I explicitly
ninja cxxthe tests fail instead of “unsupported”
Now they fail, rather than unsupported. The log isn’t especially helpful so far as I can see:
runCmd: setting set target.prefer-dynamic-value no-dynamic-values
<bound method SBProcess.Kill of <lldb.SBProcess; proxy of <Swig Object of type ‘lldb::SBProcess *’ at 0x7fb67858ecf0> >>: success
Traceback (most recent call last):
File “/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbtest.py”, line 1823, in test_method
File “/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py”, line 53, in test_with_run_command
(self.target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
File “/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py”, line 970, in run_to_source_breakpoint
return run_to_breakpoint_do_run(test, target, breakpoint, launch_info,
File “/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py”, line 892, in run_to_breakpoint_do_run
AssertionError: 10 != 5
Session info generated @ Sun Oct 17 22:23:34 2021
But if I run lldb on the binary (which isn’t mentioned in the logs… probably should be?) under test:
$ ./bin/lldb ./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.test_ref_and_ptr_dwarf/a.out
(lldb) target create “./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.test_ref_and_ptr_dwarf/a.out”
Current executable set to ‘build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.test_ref_and_ptr_dwarf/a.out’ (x86_64).
Process 1896861 launched: ‘build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.test_ref_and_ptr_dwarf/a.out’ (x86_64)
build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.test_ref_and_ptr_dwarf/a.out: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory
Process 1896861 exited with status = 127 (0x0000007f)
OK, so this looks like it’s related to libc++.so.1 not being in the ld library path - but there’s no rpath or LD_LIBRARY_PATH to find the library.
The libc++ tests build test binaries with “-Wl,-rpath,/usr/local/google/home/blaikie/dev/llvm/build/release/./lib/x86_64-unknown-linux-gnu”
Ah, here we go - by modifying the test’s source file so it would fail to compile, I am able to observe the compilation command:
build/release/bin/clang -std=c++11 -g -O0 -fno-builtin -m64 -Isrc/lldb/packages/Python/lldbsuite/test/make/…/…/…/…/…/include -Isrc/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/vector -Isrc/lldb/packages/Python/lldbsuite/test/make -include src/lldb/packages/Python/lldbsuite/test/make/test_common.h -fno-limit-debug-info -gsplit-dwarf -O0 -DLLDB_USING_LIBCPP -stdlib=libc++ --driver-mode=g++ -MT main.o -MD -MP -MF main.d -c -o main.o src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/vector/main.cpp
So… how does this work for everyone else? I’m not sure how it’s meant to work.
From some offline discussion with Pavel:
This is generally broken - it either uses the system libc++.so (making the build non-hermetic), or if you don’t enable libc++ in CMake the tests flag as unsupported/don’t fail (though other tests not specifically testing libc++ but using any standard library features are still non-hermetic, they’ll be using the system C++ standard library)
That’s all unfortunate… would love to know if anyone’s got plans/ideas/priorities for fixing this? I guess probably in a similar way to the way the libc++ tests work, explicitly -rpath when building.